changing from andRequiredProperty to addProperty not working

@dkayiwa

I want to line 81 here https://github.com/openmrs/openmrs-module-appointmentscheduling/blob/master/omod/src/main/java/org/openmrs/module/appointmentscheduling/rest/resource/openmrs1_9/AppointmentResource1_9.java

to make timeslot to be a non-required property in the the payload. I have changed it from

description.addRequiredProperty(“timeSlot”) to description.addProperty(“timeSlot”)

but it’s still not working, I will appreciate your assistance.

Can you paste the error log at pastebin.com?

this is the error

https://pastebin.com/wWaZ47pp

even after making the above changes

Can you also share details of your POST request?

{ “timeSlot”: “6d20b143-397b-11e9-be9d-d47df659ddd6”,

"patient": "b7009090-4015-11e4-8e9b-2939a1809c7e",

"status": "WALKIN",

"appointmentType": "4da187c6-c436-11e4-a470-82b0ea87e2d8",

"location": "7f65d926-57d6-4402-ae10-a5b3bcbf7986",

"date": "2019-10-14 08:00:00"

}

I want the ability to remove the timeslot data from the payload since I already have logic that works without timeslot. currently my work around for this is that i’m sending the timeslot in the payload but i’m setting it to null in the service before i manipulate the data in any way.

I just need to make it not a required property in payload because i don’t want to send my payload with it.

@dkayiwa Where could this restriction be in the code I thought it’s in the AppointmentResource and changing from

description.addRequiredProperty(“timeSlot”) to description.addProperty(“timeSlot”)

could work but it didn’t!?

Can you reproduce it in a unit test?

@jecihjoy this error is being thrown by the AppointmentValidator in the main Appointment Scheduling module…

That being said, I don’t support changing this at this time because time slot is a required field… and in fact the underlying time_slot column in the database cannot be null…

I know we were discussing on another thread about changing the design on how the appointment scheduling module works… I’m definitely interested in continuing that discuss, whether on Talk or through a design call, but we wouldn’t want to make these changes with a vision and/or plan in place.

Thanks!

Take care, Mark

1 Like

hello, thank you for your response. I did update the thread with the proposed design. If the design makes sense and is accepted, validation of the appointment payload timeslot will be best done in the service layer instead of doing it in the resource/controller but this is subject to discussion.

I’m looking forward to your response concerning the suggested design.

Regards