Hello Everyone,
I am trying to un void a voided identifier by making a post invoke call to this api endpoint with body having voided as false.
ws/rest/v1/patient/90a2f2cb-588e-49f0-983a-ac46275cb654/identifier/3c6b1c9e-2682-41f6-9469-59d8c03e6409
This however gets an error
"message": "[Some properties are not allowed to be set: voided]
Please advise how else this can be done or how to resolve above error. Thanks.
Can you give more details than this? For instance, in addition to the url, you need to show us the actual post body contents.
@niccie, “voided” is a special property that means soft-deleted. The way to set this is by doing an HTTP DELETE. See the URI Conventions section on this wiki page, or just the general API docs for each resource.
I’m not actually sure offhand how we support unvoiding. I will look into that.
That means unvoiding a patient identifier isn’t supported and in general for most resources, I doubt though if this was intentional, I think we should support it.
I have no recollection, I think when we introduced the idea of letting resources define creatable and updatable properties, that’s when this became impossible since most resources don’t list voided or retired as updatable properties.
Then I suggest we discuss this on the Monday design forum (@jthomas): “Allowing for unvoid/unretire in REST”.
Sounds good
Discussed today on the design forum (http://notes.openmrs.org/2017-10-11-Design-Forum). Our proposal is that we support a new kind of POST in our main REST controller, so that if you do this to any resource:
POST .../resource/uuid-of-resource
{ deleted: false }
Then it will unvoid or unretire that resource. You are not allowed to mix this with any other property changes, so this can only function to undo DELETE .../resource/uuid-of-resource.
@burke or others, if you have any comments please make them now, because we want to action this soon to unblock the Andela devs.
Trying to perform undelete in a RESTful manner is tricky ref. A PUT/PATCH would be closer to spec, but, since we’ve chosen to use GET, POST, and DELETE in our REST API, I agree that the proposed approach is reasonable.
If we are going to use this for both undelete and unretire, can we support either “deleted” or “retired” as the property?
What do you mean here?
I guess you mean “voided” or “retired”, right? The problem with that is that you’re assuming the client knows what is data vs metadata, probably they can tell by checking if the audit info contains a voided or a retired field, but why would they have to go through this? Why can’t we use a single deleted property for both data and metadata.
I am working with a team to look over this bug. Was a consensus ever reached on how to fix it?