Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

O3-2448 - Visit queue number customization #44

Closed
wants to merge 5 commits into from
Closed

O3-2448 - Visit queue number customization #44

wants to merge 5 commits into from

Conversation

mseaton
Copy link
Member

@mseaton mseaton commented Oct 24, 2023

The goal of this PR is to address the issues raised in https://issues.openmrs.org/browse/O3-2448 and https://issues.openmrs.org/browse/O3-2465. This PR does the following:

  1. Adds patientQueueNumber / patient_queue_number to QueueEntry / queue_entry, in order to keep this information directly in the queue model and remove the need for a custom visit attribute.
  2. Removes the bespoke code for generating queue numbers from within the core DAO and into an implementation behind an interface. This enables this functionality to be off by default, added easily if needed, and customized however implementations want.
  3. Removes the services and rest endpoints for generating and saving queue numbers as a standalone operation in favor of one that embeds this functionality in the visit queue number saving process. This enables transactional behavior around generating and setting visit queue numbers, visit attributes, visit details, and queue entry details at the same time, rather than requiring consuming code orchestrate these steps together non-transactionally.

See specific comments throughout the PR.

I have this as a Draft PR initially to show where I've been heading and looking for feedback / suggestions. This will obviously be disruptive and some work to get it working as expected in existing implementations that rely on current behavior. It will also need to be paired with changes to the O3 frontend to remove the calls to generate visit numbers, etc.

@corneliouzbett / @CynthiaKamau / @ibacher interested in thoughts / feedback. @mogoodrich FYI

@@ -74,42 +64,6 @@ public Long getQueueEntriesCountByConceptStatus(@NotNull String conceptStatus, C
return (Long) criteria.uniqueResult();
}

@Override
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic here (combined with the logic in the service below) has essentially been moved to the VisitAttributeQueueNumberProcessor. Implementations that want to retain this behavior can enable that processor by setting it on the service from a downstream module. That said, if we don't feel this is something we need/want to keep in the main codebase, I'd be supportive of moving the entire VisitAttributeQueueNumberProcessor over to a Palladium module, and not having to support that within the module.

Note, the code relocated to the processor is not exactly the same. It does not hit the DAO, but rather just iterates over the entries in the queue to achieve the same result. This may need to be optimized for speed, but didn't want to do that pre-emptively if this ultimately gets moved out of the module.

It was never really clear to me what purpose the location had here, given that queue has a location on it. If there needs to be different location than that of the queue or the visit, this will need to be looked at. That said, there are some potential issues in this method as documented in O3-2448, so it likely needs a review overally

.createQueueEntry(visitQueueEntry.getQueueEntry());
visitQueueEntry.setQueueEntry(newlyCreatedQueueEntry);
return this.dao.createOrUpdate(visitQueueEntry);
public synchronized VisitQueueEntry createVisitQueueEntry(@NotNull VisitQueueEntry visitQueueEntry) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made this method synchronized, as there tend to be situations where the queue number to generate is based on the queue entries and/or existing queue numbers assigned that exist in the database, and may need to protect against several threads generating the same queue number at the same time in different threads. See some of the comments in O3-2448

visitQueueEntry = dao.createOrUpdate(visitQueueEntry);

if (visitQueueEntryProcessor != null) {
visitQueueEntryProcessor.beforeSaveVisitQueueEntry(visitQueueEntry);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the main area that addresses the issue and allows customization. If a visitQueueEntryProcessor is set on the service, then it will be called to generate and/or populate any properties of the visitQueueEntry prior to final saving and completion of the transaction. An initial call to save happens before this is invoked in case this want to use generated data from the first save (for example, the primary key id).

*/
@Slf4j
@Component
public class BasicPatientQueueNumberGenerator implements VisitQueueEntryProcessor {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I originally had a different implementation here that was a bit more complex, but in the end I decided to make this as basic as possible. This may mean this is never appropriate for use in any real implementation, but it does serve to provide a default implementation and an example of how one would create a custom generator.


/**
* Implementation of a VisitQueueEntryProcessor which aims to retain legacy functionality using
* visit attributes
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is where I've attempted to recreate the logic from the original DAO methods that were removed.

String queueNumber = prefix + "-" + paddedString;

// Associate this queue number directly
queueEntry.setPatientQueueNumber(queueNumber);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was not in the original implementation, but I see no harm in it, and I think for a generic front-end implementation we'll need this - the data for queue number in a known, fixed attribute of the queue entry - even if is also duplicated elsewhere (eg. a custom visit attribute).

VisitAttribute visitAttribute = new VisitAttribute();
visitAttribute.setAttributeType(visitAttributeType);
visitAttribute.setValueReferenceInternal(queueNumber);
visitQueueEntry.getVisit().addAttribute(visitAttribute);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible / likely that with the new column, this is not longer behavior that is desired. But I'll leave that to others to discuss and decide.

@@ -244,16 +241,4 @@ public void shouldZeroCountQueueEntriesByBadStatus() {
assertThat(queueEntriesCountByStatusCount, notNullValue());
assertThat(queueEntriesCountByStatusCount, is(0L));
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test was moved / reimplemented below.

@@ -13,8 +13,8 @@
<concept concept_id="1000" retired="false" is_set="true" creator="1" date_created="2022-02-02 14:31:00.0" uuid="897eba27-2b38-43e8-91a9-4dfe3956a35t"/>
<concept concept_id="1001" retired="false" is_set="false" creator="1" date_created="2022-02-02 14:40:00.0" uuid="90b910bd-298c-4ecf-a632-661ae2f446op"/>
<concept concept_id="1002" retired="false" is_set="false" creator="1" date_created="2022-02-02 14:40:00.0" uuid="91b910bd-298c-4ecf-a632-661ae2f909ut"/>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The below are bugs that I found - uuids and concept name ids that were re-used and not unique

@mseaton
Copy link
Member Author

mseaton commented Oct 25, 2023

Closing this PR for now as I'm rethinking this approach and working on other issues.

@mseaton mseaton closed this Oct 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant