-
Notifications
You must be signed in to change notification settings - Fork 24
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
feat: [DHIS2-14799] Working list for follow up #3521
feat: [DHIS2-14799] Working list for follow up #3521
Conversation
@eirikhaugstulen IMHO this feature needs more design clarification. Some doubts that came to mind:
Thanks! |
…_WorkingListForFollowUp # Conflicts: # i18n/en.pot
Hey @simonadomnisoru! Thanks for the review. I had some discussions with Joakim and Karoline, and the consensus was that we put in |
...e_modules/capture-core/components/WorkingLists/TeiWorkingLists/Setup/hooks/useFiltersOnly.js
Show resolved
Hide resolved
…_WorkingListForFollowUp # Conflicts: # i18n/en.pot
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of comments that might or might not be in the back of your head:
- It seems like boolean value type filters have changed from a multi-select to a single-select. Great if we can keep multi-select for the value type.
- Boolean value type filters are stored as a string representation in Redux when you add the filter (
workingListsMeta/teiList/filters/
). When the filter is loaded from a template, it is stored as a javascript boolean primitive. Great if we can always save them as javascript booleans. The idea was to store the "client-formatted" value here, and it would be great to continue doing so (boolean for boolean value type, number for number/integer value type, ISO-string for date etc. See the converters formToClient, clientToServer etc.)
The follow-up part seems to work well with an updated backend 👍
…_WorkingListForFollowUp # Conflicts: # i18n/en.pot
🚀 Deployed on https://deploy-preview-3521--dhis2-capture.netlify.app |
# [100.66.0](v100.65.0...v100.66.0) (2024-03-06) ### Features * [DHIS2-14799] Working list for follow up ([#3521](#3521)) ([0ad3891](0ad3891))
🎉 This PR is included in version 100.66.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
TECH-summary:
The design doc also mentions that this should be available to select in the ColumnSelector, but I'm not sure if this makes sense. FollowUp is an attribute of the enrollment itself, meaning we have no good way of displaying this. Not sure what you think.