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)?
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 secondary/ sub- Stat Cat"
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/
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)?