The problem occurs with initiating the requisition. After rejecting the requisition, User deleted the requisition and tried to initiate the requisition. It was impossible.
Steps to reproduce:
1. Reject the requisition from Requisitions -> Approve view. Note: Make sure a requisition for the next period exists already.
2. Navigate to the Requistions -> Create/Authorize
3. Select proper program and facility. Click Search
4. Click Proceed. Click Delete button
5. Click again Proceed button for that requisition.
after rejecting OR rejecting and deleting the requisition, it should be possible to initiate a requisition
So if I understand correctly, v2 has the same bug (slightly different UI handling)? I was thinking that we should simply allow the user to create the requisition for the period that stops having a requisition available for it - as in, this old period becomes the period the user has to deal with. I guess there are some additional questions - should the user be able to continue with newer requisitions already created, if the old one was deleted etc.?
I am not sure where the constraints come from - what exactly was done in this ticket?
I think we can dead this and create a separate story for the delete scenarios.
This behavior was already existent before the ticket was even started. Here only thing that changed was pre-initiate validations for preiods.
I am aware that we had this bug from the start, even v2 had it, but I am not sure where the constraints come from and what was done with the validations. From what I understand we want to allow the user to create a backwards requisition in the future, when the old one was deleted.
Ok I see that it is coming from the fact, that requisition have the association. can you create a new ticket for to fill in with the edge cases? After that you can close this one.
Created OLMIS-2858. Closing this one.