Hi,
We are trying to push encounter-obs data for a Boolean concept via REST. Trying inserting data we found that if value is 0/1 for boolean concept, OpenMRS always considers it as FALSE. But sending data as true/false works fine i.e. interpreted correctly. Is this expected behaviour i.e. not allowing 0/1 instead of true/false for boolean concepts. Shouldn’t it throw exception if data is not in correct format?
Which version of the rest module and openmrs platform?
Rest Web Services 2.11.dae2e2 and OpenMRS 1.9.7
Throwing an exception for invalid values started with version 2.12 of the module. So you will need to upgrade it. I also noticed that “true” and “false” values are no longer accepted. So i made a followup fix for this at https://github.com/openmrs/openmrs-module-webservices.rest/commit/84902c6187bd88c3c485efd1344d3e2ba274f369
Hi - Did Boolean concept accept 0/1 values previously? We were under this assumption and set up our data collection forms to accept 0/1 values, which are then used in various analyses and calculations within the form. Allowing Boolean concept to accept 0/1 would be very beneficial to our project. Would this be an option?
Thanks in advance!
I believe the rest service can be tweaked to allow 0/1 for boolean fields, though i think you might still need to put the values 0 and 1 in quotes
In its current state, it takes true/false or uuid for true/false concepts. @lluismf suggested that we use something more accommodating like: https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/BooleanUtils.html#toBoolean(java.lang.String)
Though i have not tried to find out if this will take care of 0/1
Since OpenMRS 1.7.0 (released in 2010), observations for boolean concepts have been stored in the database as coded concepts (TRUE or FALSE). Prior to this, they used to be stored in the database as 1/0, but it has been a very long time since that was the case.
I suppose it would be okay to make the REST interface even more liberal in what it accepts as input, e.g. accept any of 1/0, true/false, “true”/“false”, or uuids for the true/false concepts.
But do you really need this? If you’re calling the REST web service, couldn’t your code just send true or false when submitting data?
The REST service should be smart enough to properly interpret TRUE & FALSE (case-insensitive) as well as 0 & 1 as values (either literal or string form) for a boolean concept and do the right thing. As @darius mentioned, we always store booleans as coded values under the hood, but clients of REST shouldn’t be forced to learn our data model or business rules.
If I sent any/all of the following as boolean properties within a JSON message (focusing just on the formats of the values for this example):
{
"trumpIsAnIdiot": true,
"trumpShouldBePresident": "false",
"voteForTrump": "0",
"isTheMereThoughtOfTrumpAsPresidentFrightening": 1
}
I would expect the REST API to be able to interpret them into corresponding boolean values of true or false. If the REST API couldn’t handle any of these forms, I would consider it a bug (or at least a poor choice). We (OpenMRS in our APIs) need to be doing a better job of encapsulation (rather than making clients work against our data model or perform our business rules for us) and, in the process, make our APIs higher level and easier for clients to learn & use.
Now accepting more boolean values (true/false, 1/0, on/off, yes/no) at https://github.com/openmrs/openmrs-module-webservices.rest/commit/1f2ac2091ed3864a0a26acd8d7a9673e692491d4
This is great. Thanks!
Thanks a lot @dkayiwa . That was really very quick. Is this change available in rest 2.12 omod in openmrs module resources.
No. It would require a new release of the module.
@dkayiwa you need to create a new ticket for this change, and attach it to an unreleased fix version, so that people can properly interpret this in the release notes.
It’s not okay to make changes to a ticket ( https://issues.openmrs.org/browse/RESTWS-529) that was Closed in September and release in 2.12 (two releases ago).
Could you please guide where I can find the code for module version 2.12 (that is available in module resources)
I assume you want to look at the source code for the 2.12 version, you can find it in the 2.12 tag in github
Yeh. Thanks… I wanted this…