[PACKS] #10 Add custom request units to Request export #4405
Comments
cielf
added
Help Wanted
|
@cielf I'm looking at this and in some of my test data was a bit surprised. For some reason I thought that this was supposed to (even before this change) have a column for every item from the org. But instead it has a column for every item for the exported requests. Is that what you expected too? In which case if someone is exporting requests which have ONLY used "Adult Briefs (Small/Medium) (Packs)" then that is the only item column that would get exported, right? It wouldn't export the POSSIBLE units, only the ones that are used in any of the exported requests. That's what the code is leading to based on current behavior, but thought I'd check. |
|
Or now that I'm reading the description again, it would be that if the item was used on ANY of the exported requests, go ahead and include a column for ALL of the units. In which case, I should include the implicit "Unit" unit too, right? |
The question of whether should all the items on the org be included? The easy answer would be yes, but/and a certain number of the items are not visible to partners, so I'm not so sure that it would be useful across the board(I know of one bank that only offers their assembled kits to the partners for direct request). We could, perhaps, make it all items that are visible to partners -- that would, at least, be more stable under filtering -- but I'd wonder about whether we have banks that take things out of visibility to the partners when they no longer have a reliable supply of them. It's out of scope for this change in any case. But I want to muse about this. Maybe ask the stakeholder circle for input on Wednesday. |
Short answer -- I think yes (though my ultimate reason for thinking so is stability, informed by the discussion above) But also -- what if they delete a unit (which they can, right?) . There could be item requests using that unit -- so we would need to make sure those are included. Edge cases, man. |
|
This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned. |
|
Automatically unassigned after 7 days of inactivity. |
Summary
Request export for banks includes custom request units, if applicable.
Why
This is step #9 of adding the ability to specify "packs" versus "individual" for requests
Details
If any items for the organization have customized units
Instead of having one column per item, have one column per item/unit combination. (eg. Kids (Newborn) and Kids (Newborn) - packs)
This is based on the request units available on the item, rather than whether the unit has ever been requested.
Visual Aid
N.B.
All of the changes for PACKS must be implemented behind a flipper flag "enable_packs"
1/ Flipper works by enabling or disabling a tag (for the PACKS issues, that is enable_packs)
2/ Here is a code snippet illustrating how to use it in your code, with enable_packs as the example tag:
if Flipper.enabled?(:enable_packs)
// do the thing we are guarding with the tag
end
3/ How to check out if it works manually (with the example tag: enable_packs ):
You have to enable the flipper tag on your localhost (note - the tag is stored in your db, so if you reset your db you have to do it again)
localhost:3000/flipper
userid: admin
password: password
Sign In
Click: Add feature
enable_packs
Click: Add feature
Click: Fully enable
To set it back (to check that your nifty changes haven’t broken anything when the flag is off)
Sign in as above:
click on “enable_packs”
click “Delete”
type enable_packs in the “Are you sure” dialog and click ok
Criteria for completion
Implication for UI where user selects unit:
Background
The following sections have been identified as required for the PACKS implementation. These should be implemented in numerical order.
The text was updated successfully, but these errors were encountered: