@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.
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?
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.