This configuration works as expected in the Android App.
However, in the Capture App it seems that only period-based locking is applied, because our users are still able to update events even after 5 days post-completion.
Is it bug or Intended behaviour? Would appreciate any help and advice to workaroun this. TY in advance
Thank you for your patience. You’ve correctly pinpointed that the web Capture app and the Android Capture apps are not handling the setting “Completed events expiry days” in the same way.
It appears as you explained that the Android app is able to handle both situations:
Period expiry Works in web Capture app.
Completed events expiry days Doesn’t work in the web Capture app.
Would you like to create a feature request for this on jira.dhis2.org? I could create one on your behalf. It will also support the ticket why this is important in your work. This will be a ticket that I will triage to the tracker team.
One workaround if this is a Tracker program is to use a program rule if you can figure out when edits shouldn’t be allowed from the time of one of the built-in variables:
For instance, the program rule expression could calculate if it has been five days since the incident date, if so, the program rule action will be to show error on complete which will block the user from making edits (but this assumes that the user has already completed the event before the five days).
Another workaround which might work is to make sure that data entry users don’t have the authority which allows them to ‘uncomplete’ an event (regardless of expiry days) and they’ll need to ask a user with that authority to uncomplete it for them so they can make edits. However, I still think that the best approach is to request that it works the same way as the Android Capture app handles it.
Hi @Gassim ,
Thank you very much for your response.
I completely agree with you that the Capture App and the Android App should behave the same way.
I would appreciate it if you could create a Jira ticket for this.