Redesign and refactor facility type approved products for extensibility

Description

The endpoint for searching for facility type approved product endpoints should be redesigned and refactored, to create extensibility in approved products, and for cleaner design of the search endpoint.

Points to note:

  • /facilityTypeApprovedProducts endpoint stays but is strictly used for administration, management of facility type approved products.

  • The search endpoint for getting a list of approved products would be by facility, since most questions asked of reference data start with facility. So, a possible recommended endpoint would be GET /facilities/<facilityId>/approvedProducts, returning an approved product resource, which has maxMonthsOfStock, minMonthsOfStock, and emergencyOrderPoint.

  • If approved products need to be retrieved by program, the programId would be a query parameter. Ex: /facilities/<facilityId>/approvedProducts?programId=<programId>

  • The main benefit to doing this redesign and refactor is building extensibility into approved products. Currently approved products is only grouped by facility type (for this facility type, what are the list of approved products), but there may be a requirement in the future to get a list of approved products by something else, ex. requisition group. Because of this, the search endpoint should be designed in a generic way that allows for extensibility.

Acceptance Criteria:
The sub-tasks contain their own criteria. To confirm that this whole task is completed, please do a final QA test of the ability to initiate a requisition with the proper products based on facility and program.

Environment

None
100% Done
Loading...

QAlity Plus - Test Management

Checklists

Activity

Paweł Gesek December 20, 2016 at 3:23 PM

The break up was verified in the reviews. I tested that the requisition process from initiate to convert to order (including non full supply products) works properly.

Brandon Bowersox-Johnson October 24, 2016 at 2:16 PM

please break into sub-tasks similar to

Chongsun Ahn October 20, 2016 at 2:26 PM

I feel like this one is a bit different from the RequisitionGroupProgramSchedule refactor. Facility (Type) approved products does have some meaning to the client, and there is a UI screen to manage that. We wouldn't have /facilityTypeApprovedProducts as a resource, for sure. But I don't think we would put it under programs. Programs tends to be something that crosses a number of other domain objects, so I think it makes sense to be a secondary mapper. So, something like:

  • /facilityTypes/<facilityTypeId>/approvedProducts?programId=<programId>

  • /facilityTypes/<facilityTypeId>/programs/<programId>/approvedProducts

  • /orderableProducts/search?facilityTypeId=<facilityTypeId>&programId=<programId>

Not sure if this is the best way forward. I'd like to discuss further with to get a better sense of how this story would look.

Brandon Bowersox-Johnson October 20, 2016 at 1:02 PM

Please review the proposed endpoint changes and Acceptance Criteria that I added to this ticket. If you can give it any clearer definition or a comprehensive list of all the URLs that need to change and which URLs should have PUT/POST operations, that would help the team work on this ticket with the least back and forth.

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

Details

Assignee

Reporter

Story Points

Time tracking

2w 2d 6h 30m logged1h remaining

Components

Sprint

Fix versions

Priority

Time Assistant

Created October 7, 2016 at 8:07 PM
Updated December 20, 2016 at 6:15 PM
Resolved December 20, 2016 at 3:23 PM