Require copy stat cat based on use of another

[Tiffany Little]

Wishlist.

Copy stat cats already have the ability to be required. We'd like to expand this by having something akin to a "Require based on []" attribute.

Our use case: This year we got a state grant that tech was purchased through. We'd like to track those items cataloged from those materials with a stat cat. Additionally, we also want to add another stat cat for "Item Use Type", like External checkout, In-House use, etc. The idea would be if there's a value chosen in Stat Cat 1 (Grant XYZ), then that should make Stat Cat 2 (Item Use Type) required.

Maybe an optional "Required Dependent On" field, and you can then select from other stat categories?

[Jason Boyer (jboyer)]

I think it's easier to reason out "selecting this requires that" than "this is required IF that is selected." Like adding an attribute to the stat cat values themselves, such that there could be options (or any free-text) selections for the value of Grant XYZ that *don't* require an Item Use Type selection, and other entries that may require Item Use Type or perhaps a different stat cat.

I'm not sure if we want to complicate it enough to allow multiple required stat cats, but that could be worked around by clever application of "entry X requires SC Y, entry Y requires SC Z, etc."

[Tiffany Little (tslittle)]

I think I didn't explain it well--I agree, Jason. I'm only think of the categories themselves having the dependence, rather than the entries themselves. Like if category X has a value at all, then category Y is required.

[Elizabeth Thomsen (et-8)]

Confirming that nothing like this exists, and that this would be useful

[Mike Rylander (mrylander)]

FWIW, I think what Jason describes (SC entry grows an "offer sub-stat-cat selection" capability) is significantly more flexible than the SC->SC dependency, and allows the creation of a "stat cat configuration wizard".

It would be simple at the UI level of stat cat config to
  1) show a breakdown of which entries require (offer?) a "sub-stat-cat" and which one they cascade to, so that appropriately trained staff can confirm things are correct quickly
  2) have a way to quickly have ALL entries in stat-cat-1 provide a sub-stat-cat selection from stat-cat-2 -- imagine in a grid: "select-all -> right-click -> set dependent/secondary/sub- Stat Cat"

My only question is this: is there a use case for non-required dependent stat cats? That is, should we ALWAYS force selection of a value from stat-cat-2 based on a selection for stat-cat-1, or should we allow scenarios where stat-cat-2 is optional (but offered based on stat-cat-1 value)?

[Jason Boyer (jboyer)]

Mike, I'm not certain what "offered" would mean in your comment. Do you mean like a pre-selected value that can be changed / removed, or that the SC wouldn't even be visible until offered? Other than pulling in SC's not normally visible at this OU (yuck) I don't see a use case beyond "SC X has Entry Y, so SC Z is now required."