LUI-44 bug, Is this issue still valid?

Hello all! My team of students are working on the issue below and I am wondering if you all could answer some questions that we have?

Issue: https://issues.openmrs.org/browse/LUI-44

The error is show below:

My team has verified that the error does occur. However, it occurs only sometimes (around 1/6 executions of the tests). The error is a database conflict relating to possibly a foreign key violation within the database. Also all tests in the LUI-module are passing with three currently being ignored. The tests that are relevant to this error are also passing, as shown below in a pdf document.

Test Results — org.openmrs.scheduler.web.controller in legacyui-omod.pdf (62.8 KB)

These tests relate to the SchedulerFormController, SchedulerForm, and TaskHelper classes. The code below is what we are investigating to determine the nature of error:

public void waitUntilTaskIsExecuting_shouldWaitUntilTaskIsExecuting() throws Exception {
		Date time = taskHelper.getTime(Calendar.SECOND, 1);
		TaskDefinition task = taskHelper.getScheduledTaskDefinition(time);
		taskHelper.waitUntilTaskIsExecuting(task, MAX_WAIT_TIME_IN_MILLISECONDS);
		
		Assert.assertTrue(task.getTaskInstance().isExecuting());
		deleteAllData();
}

Link to class: https://github.com/openmrs/openmrs-module-legacyui/blob/c9bb7b8ba008573568f46cb2d09ca987d309683d/omod/src/test/java/org/openmrs/scheduler/web/controller/TaskHelperTest.java#L96

We believe that the error is likely related to the call to deleteAllData() though why is currently unknown. Our questions relate to the validity of this issue. According the the Legacy UI readme at GitHub - openmrs/openmrs-module-legacyui: The legacy user interface for OpenMRS Platform 2.x is chiefly comprised of administrative functions and the patient dashboard. Apparently, a new and more contemporary UI has been introduced via a UI framework and the legacy UI is kept around for administrative functions that are not yet implemented in the new UI. To retire the Legacy UI as planned, it is required to move the implementations and modules that still rely on it in order to maintain backwards compatibility. The main idea behind this project is to move legacy UI functions into an OpenMRS module that these implementations can install until they are able to migrate away from it, since most of the implementations of OpenMRS around the world are running OpenMRS 1.9., the legacy UI is planned to be retired. Should we continue work on this issue? Should the issue be closed? If we should continue work on this issue, how do we proceed with modifying the database?

Thank you,

Team JavaMRSLUI-44_Report.txt (4.3 KB)

Looking at the issue again, you made a correct judgement that it is not of a high priority. So yes i would vote for leaving it in preference to community priority tickets. Here is an example: Can someone help me with this issue: Appointment Scheduling UI: Add Global Property for adding weekend days to Calendar in Manage Appointment Blocks Page.

Or you can just search JIRA for tickets with the community-priority label.

1 Like