Form Customization: what is the Profile/Set/Rule hierarchy?

I am trying to organise some reasonably complex manager form customisation Rules and need to know what the rules are which determine the order of precedence of these. I can't see anything in the documentation about this.

What I am trying to do is this (assume for now that these all apply identically to create and update):

1. Field Labels (Profile)
1.1. A basic custom Set of field labels.
This will apply to all templates and user groups and simply expands on the purpose of each field, for the user's info.
eg Title becomes Title (used for: manager tree | menu),
Menu Title becomes Menu Title (overrides Title if used))

1.2. Template-specific custom field labels (Set).
For some templates I want slightly differen labels, when the field are being used differently.
Where I insert a new label, I assume that this will over-ride the one in 1.1, but what about field labels which are customised in 1.1 but not changed 1.2? Should I expect these revert to the MODX default, or to the value in 1.1?

2. Hidden Fields (Profile)
For certain User Groups, I want to hide certain fields. This covers all templates.
I untick the fields I want to hide, but for the other fields, how does this operate in conjunction with the customised field labels? Do I have to re-enter all the custom labels (for visible fields) that are in 1.1? (And what about the different combinations of User Group and template? Even if there are just two of each, this potentially requires four Sets).

3. Parent-specific Default Templates (Profile)
For a particular parent resource (eg News_Page_Tpl) I want all new child resources to have a specific template (eg News_Story_Tpl).
I create a Set with Constraint Field: "parent" and Constraint: "110", the parent News resource ID.
But what happens now with the rules listed below? Do these all have to be set to match the custom field labels as defined in 1.1? If the labels are left blank, does this imply that the MODX default labels are to be used instead of another Set? And what about the hidden fields in 2.? Will these now be over-ridden by this Set, and shown?

I want to have a predictable css-type cascade effect, in which a rule is applied unless a subsequent one applies. However, the presence of the full list of fields in every Set causes me some confusion because, whether these are altered or left untouched, there is an implied meaning when interacting with another Set.

There is also the matter of default field values.. I have experienced some strange behaviour here too. If I hide a field in a "create" Set, the default value (in some cases at least) doesn't seem to apply. So for example, hiding content_type can break pages at the front end because they end up with is no content_type value at all. So, do I have to manually enter the default values for all hidden fields, even if I only want the MODX defaults?

Apologies in advance If I have introduced any confusion in the above. Any advice on the underlying algorithms and best-practice for managing a form customisation scenario such as this? [ed. note: Gav last edited this post 7 years, 7 months ago.]

I think that the rules are always applied in the order that they were created. I've never tested this, so I could be wrong.

I was afraid of that.
Unfortunately there isn't a facility to reorder them. I currently have 9 Sets in 3 Profiles, and more to come once I have this figured out.
Wouldn't it be nice to have these in a tree with draggable Profiles and Sets?

Yes it would.

Quote from: BobRay at Sep 27, 2016, 02:41 PM

I think that the rules are always applied in the order that they were created. I've never tested this, so I could be wrong.

Just for the historical record, I don't think any of this depends on the order you create sets and rules but rather the order in which they are applied.

As a for instance, you can catch yourself out by applying a template constraint in a create action on a child if you have a parent which is part of a set that applies a different default template to it's children. I had a parent called 'About' for which I had a set which set the default template of all children to the 'about' template. I also had a 'Testimonials' child of 'About' and a set that applied the default template of 'testimonial' to all 'Testimonials''s children. I had the template constraint on the create action for 'Testimonial' children set to 'testimonial' so my rules weren't being applied to my new documents and they were getting the 'about' template applied. When I removed the template contraint, my default template for the 'Testimonials' children set was applied properly on create. [ed. note: freelancewebdev last edited this post 7 years, 5 months ago.]

My assumption was that because all the rules are stored in the DB, they have to be found by query and the odds are that they will be retrieved in the order they appear in the DB (i.e., order of creation). I don't think your example proves otherwise, but as I said, I could be wrong.

I didn't make it clear. The Testimonials ruleset was created after the About ruleset so I can't see how it could be 'just' creation date that governs this. Agree it would be nice to have a definitive answer because I think this is a common issue on all but the most trivial of sites.

I'm not sure if it's relevant to your issue, but Form Customization Profiles have a 'rank' field (sets do not), and I strongly suspect that the profiles are retrieved in order of rank.

TBH, I almost never use Form Customization, so I'm probably not the best person to answer this.