Currently, the frontend uses the same “edit” privilege to control both viewing forms and editing previous encounters of a specific encounter-type. This creates a challenge when trying to restrict certain users from editing past encounters while still allowing them to view associated forms.
Read-Only View Mode: Implement a read-only version of the form that allows users with restricted edit privileges to view past encounters without being able to modify them.
Conditional UI Changes: Hide the “Edit” and “Delete” buttons in the visits summary for users who do not have permission to edit previous encounters. (we can pass the required privilege from the frontend json config)
Thanks @dkayiwa.
Yes, currently, the frontend already hides the “Edit this encounter” and “Delete this encounter” buttons when the user lacks the edit privilege entirely.
However, in our case, the challenge is different. We need to restrict certain users who have the edit privilege from editing previous encounters while still allowing them to submit new ones.
A real-life example is a nurse and a doctor:
Both should be able to submit a form (meaning they both have the edit privilege).
However, only the doctor should be able to edit a previously submitted encounter, while the nurse should only have read access to past encounters.
Since the current privilege system doesn’t distinguish between editing new vs. previous encounters, we need a way to enforce this additional restriction
What happens when you try creating a user who has the Add Encounters privilege but not the Edit Encounters privilege? Are they not able to submit new encounters? Are they able to edit existing encounters?
