Error Editing voided property.

niccie (Eunice Njeri) 2017-10-05 09:15:14 UTC #1

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.

Supporting Void/Retire Reason via REST API

Design Forum 2017-10-11: Unvoiding/Unretiring via REST

dkayiwa (Daniel Kayiwa) 2017-10-05 14:52:31 UTC #2

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 (Eunice Njeri) 2017-10-05 15:07:36 UTC #3

@dkayiwa,

I am making a post with body content as below:

{"voided": false}

darius (Darius Jazayeri) 2017-10-05 17:46:05 UTC #4

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

wyclif (Wyclif Luyima) 2017-10-05 17:48:47 UTC #5

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.

darius (Darius Jazayeri) 2017-10-05 17:56:15 UTC #6

@wyclif do you recall if there was ever a design discussion or talk thread on this topic?

wyclif (Wyclif Luyima) 2017-10-05 18:14:37 UTC #7

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.

darius (Darius Jazayeri) 2017-10-05 18:38:27 UTC #8

Then I suggest we discuss this on the Monday design forum (@jthomas): "Allowing for unvoid/unretire in REST".

Propose a Design Forum Topic

wyclif (Wyclif Luyima) 2017-10-06 17:37:30 UTC #9

Sounds good

darius (Darius Jazayeri) 2017-10-11 19:09:27 UTC #10

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.

wyclif (Wyclif Luyima) 2017-10-23 20:31:27 UTC #11

@Burke any comments? We need to have this ticketed and marked as ready for work asap.

burke (Burke Mamlin) 2017-10-23 22:09:19 UTC #12

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?

willa (Willa Mhawila) 2017-10-24 01:57:03 UTC #13

What do you mean here?

wyclif (Wyclif Luyima) 2017-10-24 21:01:00 UTC #14

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.