-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release v1.32.0 #837
Merged
Merged
Release v1.32.0 #837
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Problem Before we remove the NRIC filter, we want to have an option to hide the NRIC filter for pipes created after a certain date. ## Solution - Create a generic LD flag for inputs, and allow the NRIC filter LD flag to set a certain timestamp on LD such that pipes after this timestamp will not show the input - Remove the step accordion if no input is present after hiding specific inputs ## Tests - [x] Only NRIC filter input is hidden after 12th Dec (can change this date nearer to release) - [x] NRIC filter input is still present for pipes created before 12th Dec - [x] Other inputs are still present regardless of timestamp
…ht (#830) ## Problem Rich text editor has an infinite scroll, causing the variable suggestion box to go off-screen, making it difficult to select variables. ## Solution Set max-height property for the editor to ensure it scrolls after the max height. **Improvements**: - RTE will be scrollable after the max height set. ## Before & After Screenshots **BEFORE**: <img width="863" alt="Screenshot 2024-12-19 at 2 24 08 PM" src="https://github.com/user-attachments/assets/ee1223d2-4c78-40bb-9f2a-57b66723d364" /> <img width="856" alt="Screenshot 2024-12-19 at 2 24 41 PM" src="https://github.com/user-attachments/assets/6d492f28-f684-40bb-bf69-20f5ea4f7dc9" /> **AFTER**: <img width="856" alt="Screenshot 2024-12-19 at 2 25 25 PM" src="https://github.com/user-attachments/assets/9fc66c9a-cc5c-4fcb-890c-5861315ad45f" /> ## Tests Note: this is a frontend change, no impact to backend functionality. - [x] RTE content is updated and saved correctly - [x] Variable suggestion box opens and selected variables are inserted into RTE correctly.
# Problem Users face JSON parsing errors when using variables (likely due to `"` within the variable content). # Solution Escape variable content so that `"` or other special characters within content do not cause errors. **Improvements:** * Add schema to validate Data field input: if user is attempting to input JSON data, check that its a valid JSON * Safely escape variable content for use in data field # Tests - [x] Existing Pipes with Data fields should run as expected - [x] Escaping does not alter variable content - [x] String data inputs are allowed (there are some existing Pipes that do this - [x] Empty data inputs are allowed - [x] Invalid JSON inputs are handled gracefully with correct error thrown in Test step
### TL;DR New MyInfo Child fields from FormSG returns data with `.` as part of the key (e.g., `child.birthdate`). Libraries like `lodash.get` treat `.` as a path separator for nested properties (e.g., accessing `child.birthdate`), leading to incorrect value retrieval or failure. ### What changed? - Replaced the `.` in keys with `_` to avoid issues with obtaining values. ### How to test? 1. Run the test suite to verify all scenarios pass 2. Test with actual FormSG fields from MyInfo Child ### Why make this change? The standard lodash.get function doesn't properly handle cases where object keys contain dots, leading to incorrect property access. This implementation provides more accurate property resolution.
### TL;DR Updated Custom API header handling to ensure: * `Content-Type = application/json`, if not set by user * `Content-Type` set in Connection step is not overwritten by `Content-Type` set in Custom Headers ### What changed? - `Content-Type` header is now set for all requests to `application/json` instead of Axios' default `application/x-www-form-urlencoded` ### How to test? 1. Make a request to the custom API endpoint with no `Content-Type` set 2. Verify that the `Content-Type` header is present and is `application/json` 3. Create a Connection in **Add connection** step with a custom `Content-Type` 4. Verify that the `Content-Type` header is present and matches what was set 5. Add a different `Content-Type` to **Custom header** step 6. Verify that it does not overwrite the `Content-Type` set in the **Add connection** step ### Why make this change? The Content-Type header should be set consistently for all requests. The previous implementation only set it for requests with headers specified in the Connection step.
### TL;DR Added support for parsing and formatting MyInfo Child birth dates in FormSG date fields. ### What changed? Added handling for MyInfo Child birth dates which come in dd/mm/yyyy format within the FormSG date field converter. Note: we maintain a single converter for FormSG date fields while accommodating the MyInfo Child date format, to minimise confusion for users. ### How to test? 1. Run the unit tests to verify the new date parsing functionality 2. Verify that the MyInfo Child birth dates can be transformed to other formats correctly 3. Ensure existing date formats continue to work as expected ### Why make this change? MyInfo Child sends birth dates in a different format (`dd/mm/yyyy`) compared to other FormSG date fields, which sends dates as (`dd MMM yyyy`). This change ensures compatibility with MyInfo Child data while maintaining a single, consistent converter for all FormSG date fields to minimise user confusion. --------- Co-authored-by: Ong Guan Hong Malcolm <[email protected]>
## Details - Hide isVisible field from formsg - Update to Form ID instead
pregnantboy
approved these changes
Dec 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Details