Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Add unit tests for initiating a requisition

Description

Add five unit tests testing initiating a regular requisition when a previous requisition exists. It should be only possible to initiate a regular requisition if the previous requisition is the AUTHORIZED state (or higher).

By previous requisition, we mean the last (by period) regular requisition with the given facility and program.

This unit tests should be very similar (reuse code) and differ by the status of the previous requisition:

1) Initiating a requisition when the previous requisition has the INITIATED status - should fail
2) Initiating a requisition when the previous requisition has the SUBMITTED status - should fail
3) Initiating a requisition when the previous requisition has the AUTHORIZED status - should succeed
4) Initiating a requisition when the previous requisition has the APPROVED status - should succeed
5) Initiating a requisition when the previous requisition has the SKIPPED status - should succeed. Make sure this case is handled

This is the previous description of the ticket, use it for reference only, not for source of acceptance criteria.

Previous description

There should be additional validation in the API to not allow a user to initiate a new requisition until the previous period's regular (non-emergency) requisition is approved.

Details

  • This would look for an approved authorized requisition (or a requisition that is past the approved authorized status, such as approved or converted to order+). It would look at this facility and for this program.

  • Mary Jo says there will always be a previous period, even when the system is first implemented they will load some historical data into it. Even so, I think we do need logic that if there is no previous period or no previous requisition in the database, we need to allow the user to use the system. Perhaps they are just getting started using openlmis at this facility for this program for the first time. So I would say that if there is no preceding period, or if the preceding period did not have a regular requisition, then we allow them to initiate one.

  • So the only situation where we block them from initiating is when we found a regular requisition for the preceding period that requisition is in a status that is prior to its final approved authorized status meaning the last approval in the supervisory node tree. I believe looking at the status can tell you that.

  • We will always allow emergency requisitions, so this validation restriction only applies to regular requisitions.

This is an API ticket/bug. But there may be a tiny bit of UI work; if there is no requisition to initiate (because the previous one is still awaiting approval authorization), the UI needs to show that and not allow them to initiate. That might already work that way. So UI code might not be needed. But please verify and address if needed.

Looking Forward
In the future (after this ticket) when more of the Order functionality is finished, this validation will actually change to prevent a new requisition until the previous one is converted to order. But that is not all built yet.

Also, we will also be implementing a way to skip requisition (and the period they are associated with). This would happen when perhaps a facility didn't submit a requisition one month due to flooding or something and then they need to initiate a new one but don't want to create a "fake" one and push it all the way through to start a new requisition. So in the future when the "skip" functionality is in place, we will update this validation to also allow you to create a new regular requisition if the previous period was skipped.

Acceptance Criteria

  • Add Verify API validation as specified above: it should allow a new requisition or prevent a new requisition in the situations as listed above

  • Add automated tests for these cases (including the failing cases)

  • Make sure UI supports this validation

let us know if you have questions about this validation logic-

Environment

None

QAlity Plus - Test Management

Checklists

Activity

Paweł Gesek 
November 7, 2016 at 5:04 PM

I updated the ticket to add five tests based on the previous requisition status.

Brandon Bowersox-Johnson 
November 4, 2016 at 10:50 PM

Okay, please use this same ticket and revise it to say that the only remaining work is the Unit Test. Thanks for your research!

Paweł Gesek 
November 4, 2016 at 5:11 PM
(edited)

the only thing that I see missing here is this unit test for the RequisitionService. Should I change this ticket a bit, or close this and create a new one for the unit test?

Paweł Gesek 
November 4, 2016 at 5:09 PM

This is our current code that handles this

Requisition lastRequisition = requisitionRepository.getLastRegularRequisition( facilityId, programId ); if (null != lastRequisition && lastRequisition.isPreAuthorize()) { throw new InvalidRequisitionStatusException("Please finish previous requisition"); }

I believe it is missing a unit test.

Paweł Gesek 
November 4, 2016 at 5:04 PM
(edited)

I verified that our UI works the same way as v2.

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Story Points

Original estimate

Time tracking

2d 1h 30m logged

Sprint

Fix versions

Priority

Parent

Time Assistant

Created October 28, 2016 at 9:36 PM
Updated November 22, 2016 at 4:29 PM
Resolved November 21, 2016 at 6:22 PM