GSoC’26 Week 2 : Digging deep and making the progress visible

Till this time, I guess we have discussed enough to get start the work and start building the house. I can say like actual work started from this week and yeah I have come across a lot of things where some changes already got shipped to PROD, some got ready to put on stairs and some get their manufacturing started 🙂.

So let’s talk more about the what we have done, challenges tackled and how solved that and yeah those PRs .

1. Patient Audit Log API :

What done ?

Made a REST endpoint to fetch patient audit logs. It retrieves the paginated audit history for a patient. This was the quick request for O3 Audit Module and I guess I delivered it same. After the weeks of modifications and continuous review, we have finally shipped this to the PROD. This is that API and we have detailed doc here🔗.

GET /openmrs/ws/rest/v1/auditlogs/patients

And I also made the API endpoint to fetch the audit details for a single revision, means what all changed for that particular revision id.

GET /openmrs/ws/rest/v1/auditlogs/{revisionId}

Finally this is the PR 🔗 whose commits not just got reviewed but placed in the main branch too 🥳.

Challenge ?

Though I did not get such a strong one, because I took a lot of help from existing code and it made the work smooth. But in the review part, there was interesting problem occuring on the patient API search params because we were using patient name and identifier which seems not to be standard search param because our aim is to return the audit history for a single patient and patient name or identifier can have same for more than one patient and thus it can give the list of more than one entity which defeats the purpose of this API so instead of that now we are using the unique identifier of patient and in this case uuid and id , that’s perfect for this and solves the problem 👍.

2. Security Audit Logging :

What done ?

This is whole new feature we are implementing on the audit module. It’s purpose is to audit the security events like login success/failed, logout, password change or reset and session timeout. This is been “work on progress” since long time and finally it’s is in review period now.

As this is whole new feature, I have implemented like most of security event using the AOP way except the logout because we already UserSessionListener which publishes this event because earlier I’m using the custom event publisher but I got this idea from the community and hence improved it to existing listener.

And we also need a user interface to show these audits on the OpenMRS admin dashboard and for that, used the legacy JSP design page and btw this is how security audit dashboard looks like :

I can’t say like all this is work for week 2 but instead it was something I already started working on and finally made it for review after solving the major challenges we facing(I’ll talk) . This the PR 🔗 for this one, still needs lot of iteration I guess.

Challenge ?

1. The major challenge for this is to implement the whole thing on Audit module only and removing the any code dependency from the OpenMRS core module. And lot of that I did too but for auditing the authentication event like login success/failed, account locked , I was juggling with the correct approach because I have thought of easier way to direct publish those events from core and listen to them on audit module and save it. We have UserSessionListener which publishes login success/fail but I also need to audit account locked event which it has not. Then I dug deep into the HibernateContextDAO#authenticate and surprisingly it was not that hard which I was assuming.

Solution was to use @Around advice around the authenticate method and there is four possible output for this method which we use for logging authentication events. And thus I solve this hurdle and made this feature completely independent of core module.

2. Second challenge was short and just needed one line change which is this .

 if (AopUtils.isAopProxy(joinPoint.getTarget())) return;

Ok so why it was the challenge 🤔 ? While implementing the PasswordAuditAdvice which responsible for auditing the password change events like change or rest password and it’s request. First I used the old way to intercept the methods by implementing the AfterReturningAdvice and then register the advice during module startup which works for OpenMRS style but then I though of using the modern way by using complete annotation way and that’s where the bug got added and new challenge got created.

Problem using the annotation style way is that we are creating kind of extra proxy apart of what OpenMRS already creates for every service classes so the problem is now it’s two proxy created and AOP method executes two times each for each proxy hence resulting in duplicate execution behaviour. And then I started digging deep int how it create proxy for each service class and then how @Aspect created another proxy . This is one of interesting thing I learned while debugging it, which is how each service method executes in OpenMRS and about the TransactionProxyFactoryBean , btw this is my thoughts :

After I got to know about the double proxy created and after getting reference from existing core code, I solve it by checking , whether the object or in this case service class itself a spring proxy if so then skip that bcz we already have created one using @Aspect and thus it solves the problem of executing method twice.

Uff 😮‍💨, that was long debugging session and it got me lot of learnings for just one problem.

3. New bugs raised

What ?

This week we got two new bugs from the existing audit module code, both is from the /auditlogs rest endpoint.

1. First bug is that endDatefilter on request param of audit log API is exclusive which means if we pass startDateas 2/06/2026 and endDateas 5/06/2026 then it returns the audit log till 4/06/2026 only. So we need to make endDatealso count in the range. To fix this we have to parse the endDateas the end of day means at 23:59:59.999. which could include all the logs till this point. I have fixed and this is the PR 🔗 which is in review.
2. Second bug is that when the we pass wrong user on the username filter of audit log it resolve it as null and further pass on the DAO method which think like user has not passed the username and returns the default result which turns out to be returning all the list. This is what I will work on next week though we discussed around this already.

Okkk , cut cut .. 🎬 the show is over 😅, so this is the long one and so the work done is 😮‍💨. Got lot of new learnings this week and shipped the new changes. Great if you came all long till here 👍 and see you in the next week ✌️.

btw these are are PRs list till this point, worked on or may be needed to work more. PR1 , PR2 , PR3