Removed fix version since it was decided to not fix this issue at this time.

Conversation:
This is an issue with the common code handling an older way we were designing the rest controllers and specifically the date (Calendar type) field. Before, we were not formatting the date to a string format, and kept it in the long number type format. This is tough because this is requisitions and we did not want to make any changes to how the existing endpoints worked. For this to be fixed and not make changes to existing behavior, we’d have to look into handling both the long number version of the date field and also the string version, refactor org.ssdt_ohio.model.rest.PatchMappingUpdater, or change the requition controller methods to use a different mapper, but these may not be ideal or what we'd want exactly. Would be good to talk it over.

found an issue when trying to update calendar field. Sent stack trace to dev

testing-notes: use build 3

these changes, like seen in 5203, include new item and charge endpoints. Along with usual rest controller testing, include testing the “/item” and “/charge” crud endpoints. the new GET method for item and charge is of the following forms: “/item/< item UUID>” and “/charge/< charge UUID>”. and “/item” and “/charge” but with included query parameters. POST and PUT both expect the url to just be “/item” and “/charge”, but the Request’s body json data should include item dto data and charge dto data, e.g.
{ "requisitionItemDto": { "id": "123", ...and so on }, "requisitionChargeDto": { "id": "456", ...and so on } }

For the two new GET endpoints for both item and charge: the ones with the inlcuded UUID, will get a singular item or charge with that ID. The second mentioned GET endpoint expectes any query parameters that is then used to find and flter items, with a hard coded max result size of 50 items.

starting this cleanup while I wait on bamboo builds for 5203