Done
Pinned fields
Click on the next to a field label to start pinning.
Details
Details
Assignee
Mateusz Kwiatkowski
Mateusz KwiatkowskiReporter
Sebastian Brudziński
Sebastian BrudzińskiStory Points
2
Original estimate
1d
Time tracking
6h logged2h remaining
Components
Sprint
Add sprint
Fix versions
Affects versions
Priority
Time Assistant
Time Assistant
Created October 17, 2017 at 9:30 AM
Updated November 13, 2017 at 6:55 PM
Resolved November 1, 2017 at 7:44 PM
Per the requisition update endpoint contract, the stock adjustment reasons for line items are provided using UUID of a reason and quantity to adjust. There's however no validation that the reason of the provided UUID exists. The requisition update endpoint should fail an attempt to create such reference. The correctness of the reason should be verified against the snapshotted reasons stored in the requisition object at the time of the initiate.
Repro steps
Actual repro of the issue can be difficult to achieve on the UI. In Malawi, this happens due to users having a cached version of the adjustment reasons. Since this ticket tackles backend only though, we can simulate what happens in Malawi.
Initiate a requisition on the UI
Add an adjustment for one of the line items
Click sync with server and capture the JSON object that is sent to the server
Modify the JSON so the reasonId in the adjustments for the line item is incorrect (points to a record that does not exist)
Send the modified JSON via update requisition API endpoint
Currently: update passes, even though the reasonId is incorrect; Expected: update fails
Acceptance criteria:
Validation exists and prevents saving a requisition when incorrect reason ID is sent
Correctness of the reason ID is validated against the available reason set that was snapshotted at the point of initiating the requisition
400 error code and proper error message is returned on the validation failure