My OpenMRS Fellowship Journey 2024: Wikum Weerakutti

Community
,
17

Hi all,

The primary work on both main tickets, which I’ve been focusing on since the beginning of my fellowship, is now finished, and I’ve had the opportunity to begin several new projects. Let’s delve deeper into these developments

TRUNK-6203: Global property access should be privileged

Implementing this feature was crucial for enhancing OpenMRS security. It restricts access to global properties for non-privileged users, while still allowing them access to essential tasks, such as reaching the login page.

After integrating this feature into the CORE, we reviewed each module in the 2.x/O3 reference applications to ensure they had access to global properties where necessary. For more details, please refer to my previous post.

OMRS-131: Detailed Audit Logging

I have reached a significant milestone with this ticket by successfully implementing Hibernate Envers in the OpenMRS core. Now, OpenMRS can audit changes to almost all tables in its database. However, we had to exclude two tables from this implementation, as Envers was unable to auto-generate audit tables for them without requiring a lot of changes to our code base. These two tables are:

I made a few commits to completely implement Envers. You can find them here

We are keeping auditing disabled by default. You can find more details on how to use this feature on our wiki page.

I am currently developing a backend module that users can utilize to access audit logs. The main goal of this module is to offer all the necessary endpoints and services for accessing audit data, as well as to provide a simple user interface for viewing audit logs.

You can track the progress of this module and join the discussion on my OpenMRS Talk post, or by visiting my GitHub repository:

I am going to use this post to address some of the questions you might have about this implementation.

1. Why do we implement this straight to the CORE rather than first trying this on a module?

When Envers audits a table that includes fields referencing another table, it can only audit those fields if the referenced table is also audited. For example, we can only audit the person_id field in the person_address table if the person table itself is audited.

@Entity
@Table(name = "person_address")
public class PersonAddress extends BaseChangeableOpenmrsData implements java.io.Serializable, Cloneable, Comparable<PersonAddress>, Address {
	
	public static final long serialVersionUID = 343333L;
	
	// Fields
	@Id
	@Column(name = "person_address_id")
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	private Integer personAddressId;
	
	@ManyToOne
	@JoinColumn(name = "person_id")
	private Person person;

Due to this, starting the implementation in a module would be inefficient, as we would have to mark many of the module table fields as Not Audited.

2. Can we audit database views using this feature?

No, this feature only records changes made to the database, such as creations, modifications, and deletions. The primary goal is to audit changes to the database itself, not user actions. I explored the possibility of auditing views using Hibernate Interceptors, but we decided against it. Implementing such a system would record all database calls, potentially creating a large amount of unnecessary data and noise

3. Can we select what tables to audit or ignore?

Currently, our implementation does not support selective auditing. You can either enable or disable auditing entirely.

I hope this clears up any questions you might have. If you have more questions or want to share feedback, feel free to drop them on our Talk post: New Audit Log System for OpenMRS: Seeking Feedback and Suggestions.

O3-3424: Better O3 Setup 2024

The main goal of this epic is to enable better, easier O3 installing and configuring. I have been assigned some of the tickets related to this and I started working on one of the main tickets related to this epic.

This tool allows users to customize their version of the RefApp by using a simplified distro.properties file that includes just three key fields:

  1. parent.artifact
  2. parent.groupId
  3. parent.version

Users can further tailor their servers by overriding default properties. You can find details on the ticket page. I have submitted a pull request on the SDK for this feature and am currently awaiting its review

Pull request: O3-3424: Distro Inheritance Tool

GSOC-2024: Validating and re-working (updating) the OpenMRS PatientFlags module

For the past few weeks, @manojll was hard at work on this project. He has submitted pull requests for most of the project’s features and completed his mid-term evaluation last week. I am truly impressed by his passion and dedication. I would also like to thank @dkayiwa for the continuous support provided to both Manoj and myself throughout this project.

In addition to my main tasks, I’ve also been assisting community members where possible. A significant issue I addressed was a bug in the SDK that failed to add configurations for the O3 setup. You can view the commit that resolved this issue here: Resolve the Configuration Extraction Error for O3. Special thanks to @njiddasalifu for identifying and reporting this bug.

Thank you all for taking the time to read this update. Please feel free to share any feedback you might have.

2 Likes