[PACKS] # 1 Add custom request units at organizational level

[cielf]

Summary

Add custom request units at organizational level (requires PACKS #0 completion first)

Why

This is step #1 of adding the ability to specify "packs" versus "units" for requests

Details

Add custom request units used to the organization, on both edit and show.

Prompts, fields and buttons for edit:

Custom request units used (please use singular form -- e.g. pack, not packs) :
Custom request unit : [text field] [Remove]
[+Add another unit]

For show:

Custom request units used:
list the units, one to a line
none, if no units selected

Rules:
Can not be duplicated within the organization
Can not be removed if any items are using the unit.

These will be used as the basis for allowing customized units on specific items.

N.B.

All of the UI changes for PACKS must be implemented behind a flipper flag "enable_packs"
Here are the things you need to know to work with flipper:

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

Screen hint for organization edit placement

Screen hint for organization view

Note from dev discussion

It's not problematic to remove a unit that has previously been active for item (and used in requests). The restriction in the Rules section above is only for units that are currently active on an item.

Criteria for completion

• functionality as described above
• tests that support the functionality as described above

Background

The following sections have been identified as required for the PACKS implementation. These should be implemented in numerical order. The pre-work [PACKS #0] must be completed first.

[Eccatoe]

I can take this one 👍

[github-actions]

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.

[awwaiid]

Merged!