O3-2446 - Queue module service, status, and priority configuration #49
Conversation
… refer to either uuid, mapping, or name.
…and statuses that differs from the default
… and statusConceptSet properties, and also to retrieve the allowedPriorities and allowedStatuses concepts.
mseaton
changed the title
| //but there are no alternative suitable methods to get a List of Concepts that exactly match a given name | ||
| c = getConceptService().getConceptByName(conceptRef); | ||
| if (c == null) { | ||
| throw new IllegalArgumentException("Unable to find concept: " + conceptRef); | ||
| } |
There was a problem hiding this comment.
I discovered in testing that the method I was previously using (getConceptService().getConceptsByName(conceptRef)) does a fuzzy-match (eg. partial match) rather than an exact match, so it was matching on too many concepts. Unfortunately, there is no public method in the ConceptService to get back all Concepts that exactly match a particular name, and the one above that I am using will just log a warning if multiple names are found and return the first one, which really isn't ideal, but given that it is also what is used in the new Core 2.6 method that accomplishes the same as the above, I went with it. We likely should address this in core, and provide some additional (better) options.
There was a problem hiding this comment.
IIRC, the method in core was basically pulled straight from HTMLFormEntry and similarly didn't want to mess with what already worked. I agree having something like getConceptsByExactName() in core would actually be really, really useful for these cases where we're using concept names as concept identifiers.
| } | ||
| Location isExistentLocation = Context.getLocationService().getLocationByUuid(location.getUuid()); | ||
| return isExistentLocation != null; | ||
| } |
There was a problem hiding this comment.
This seemed rather pointless. We already check for null earlier in the method, and we don't typically check whether a nested property is actually saved or not, so I removed this check.
Per my added comment above, we do probably want to validate that the location is actually tagged as a Queue Location, but I'll leave that for a separate ticket if desired.
| @PropertyGetter("allowedStatuses") | ||
| public Object getAllowedStatuses(Queue delegate) { | ||
| return services.getAllowedStatuses(delegate); | ||
| } |
There was a problem hiding this comment.
I'm not entirely sure if this is the right way to support this, but adding these to the Queue resource seems the most straightforward and helpful.
| //but there are no alternative suitable methods to get a List of Concepts that exactly match a given name | ||
| c = getConceptService().getConceptByName(conceptRef); | ||
| if (c == null) { | ||
| throw new IllegalArgumentException("Unable to find concept: " + conceptRef); | ||
| } |
There was a problem hiding this comment.
IIRC, the method in core was basically pulled straight from HTMLFormEntry and similarly didn't want to mess with what already worked. I agree having something like getConceptsByExactName() in core would actually be really, really useful for these cases where we're using concept names as concept identifiers.
|
It's kind of weird to throw IllegalArgumentException if the concept does not exist. |
See: https://openmrs.atlassian.net/browse/O3-2446