paleu256
(Philip Aleu)
14 February 2026 09:16
1
Steps to Reproduce
In Capture, create/open Event A for Org Unit A .
Upload File A into the File-type data element.
Save the event.
Create/open Event B for Org Unit B (same program/stage and same file-type data element).
Upload File B into the same data element.
Save the event.
Go back and open Event A (Org Unit A).
Click/open the file shown in the file-type data element.
Actual Result
Event A opens File B (the most recently uploaded file for that data element), not File A.
It behaves as if the file reference is not stored/loaded per event, but instead resolves to the latest uploaded file across events.
Expected Result
Event A should open/display File A (the file uploaded for Event A).
Impact
This is a data integrity / patient-record correctness risk :
Users cannot reliably view the correct attachment per event.
Historical event attachments appear to “change” after new uploads in other events/org units.
Frequency
Always
Reproducible consistently in 2.42 and on Play.
Gassim
(AL-Gassim Sharaf Addin)
16 February 2026 14:17
2
Hi @paleu256
Thank you for reporting this issue. I can reproduce the issue. It appears that I don’t need to upload a new file for it to appear and all it takes is to go to another event click on the file link and view it then return and it will “replace” the previous file. It’s really strange, the links are all the same ids but will have different file:
I’m triaging this to the @dhis2-tracker team. Thank you!
Gassim
(AL-Gassim Sharaf Addin)
1 March 2026 17:22
3
Hi @paleu256
This issue has been fixed. Here’s the Jira ticket: Jira
Thank you for reporting!
m.siusko
(Mikhailo Siusko)
2 March 2026 08:19
4
Hi!
@paleu256 ,
@Gassim ,
We face the same issue with image value type
Will the fix also affect image value type DEs?
paleu256
(Philip Aleu)
3 March 2026 20:00
6
It definitely will, handles both pdfs and images.
Gassim
(AL-Gassim Sharaf Addin)
9 March 2026 13:32
7