Since I'm a programmer and I try to respect databases normals forms, I try to always use a relation when I should do so.
And when I say that I try is because if i wanted to go "full normal", the z_grouping attribute in the present example should be a relation to avoid data redundancy. I did not do it for a couple of reasons that we could debate in a philosophical discussion but for the current example, let just say that we can't be perfect but we can be better
For cases like this one, I like to use a "generic" object in wich I store values for a wide range of usage.
Object definition wich i lovely called z_dropdown :
z_grouping (string) (It is the english name for my z_groupement attribute)
z_value (string) (It is the english name for my z_valeur attribute)
(Other attributes are generated automatically)
(cdtj there is one of your invention in there, z_generate_name used to generate a unique asset tag : Concat an auto-incremental ID to CI name . Still rocking it !)
If I want to store your values 'Very-High', 'High', 'Medium' ,'Low', I would add 4 items with the same z_grouping values.
z_value/z_grouping
Very-High/grouping_1
High/grouping_1
Medium/grouping_1
Low/grouping_1
On the object on wich the new dropdown is needed, add an attribute wich is a SREL to z_dropdown
And then I add a dropdown with a whereClause on the z_grouping attribute on a detail form :
<PDM_MACRO name=dtlDropdown hdr="Example" attr=z_typeEvolution factory=z_dropdown whereclause="z_groupement = 'grouping_1'">
To add element in the dropdown, you just need to create a new item in z_dropdown with the same z_grouping!
To manage all this via the GUI, you need to create both list_ and detail_ forms and a custom admin menutree
If interested I can share the steps involved. Takes maximum one hour to implement.