As an implementer/admin, I want to configure which programs' requisition forms include the "Date physical stock count completed" field, so that some programs can collect this data while other programs can keep their current process without this added data entry effort or re-training.
This work is part of the "connecting requisition and stock management" work described here: https://openlmis.atlassian.net/wiki/spaces/OP/pages/114234797/Connecting+Stock+Management+and+Requisition+Services
This ticket makes configurable. That ticket adds a new date field globally, but the Product Committee has determined it needs to be configurable. This work includes:
Add "Enable field for Date Physical Stock Count Completed" toggle (on/off) as part of the Program Settings in the API endpoint. This is a new field in the /api/programs/UUID endpoint in Reference Data (and in the schema and model for Program). It is a boolean that is "true" of "false" in the JSON, similar to "showNonFullSupplyTab" setting.
Default value for all programs will be False (set all to false when we create this new field).
Add business logic in Requisition Service to use this true/false program setting configuration to control which requisitions get this date field. We want the requisition object--when it is initiated--to include a true/false indicator of whether this date field is enabled for that requisition.
Update the UI to make the Requisition UI support requisition forms both with and without this field. The UI should look at this boolean setting and only show the new modal added in on Requisitions when it is enabled.
For requisitions WITH it enabled, the functionality works like OLMIS-2833. The modal appears at the proper steps of the workflow. When the date is set (not NULL), it shows up in the Requisition Header and on the paper print-out.
For requisitions without it enabled, the new modal does not appear and the date field stays NULL. Because the date is NULL, it does not display on the Requisition Header or in the Requisition print-out for such a requisition.
Adding an Admin UI checkbox for this configuration in the Administration > Programs > Program Settings tab. Screenshot attached.
Update Reference Data /api/programs/UUID endpoint to have this new "Enable field for Date Physical Stock Count Completed" boolean program setting. This includes updating RAML and adding schema to store the new field (with Flyway migration).
Update Requisition Service to use this true/false setting to control which requisitions get this date field.
Update Requisition UI to use this program setting to determine whether the requisition gets the new modal or not.
Update Admin UI to add checkbox to the Program Settings tab.
Include automated tests to make sure this setting works both ways (developers please brainstorm details of what tests).
Re-QA the feature to make sure the feature works correctly when this setting is Enabled.
Note: I added proposed documentation into the Implementer/Administrator Guide: https://openlmis.atlassian.net/wiki/spaces/OP/pages/112138794/Implementer+Administrator#Implementer/Administrator-SetupPrograms,ProcessingSchedules,andPeriods
I tested the ticket and found the following issues, occurring on both browsers:
1. Different text in program edition in Administration than on the mock-up; it should be:
next to the checkmark: Enable field for Date Physical Stock Count Completed
in italics: Require users to enter this date when a requisition is Submitted; the date can be edited when a requisition is Authorized.
2. The date is not visible in print preview of submitted and authorized requisitons.
3. One can authorize a requisition with a blank date field. Despite that, the date physical stock count completed is then (i.e. when approving the requisition) visible above the comments section.
4. When authorizing, one can change the date that was chosen while submitting to an earlier one. But probably this is not an issue, as I don't see any validation in the acceptance criteria.
#2 Actually it will be implemented in other ticket:
#4 As you said there is no ACC for this so I assume that it could be an earlier date.
Regarding #4, it is perfectly fine for the user to change the date to a different date, including an earlier date, when Authorizing. The authorizer has all of the same ability to adjust that date field as the Submitter does. So I think #4 is fine this way.
I checked, and the issues that I reported no longer occur, so everything works correctly.