2.05 upgrade notes on Form Customization

Just a few notes and possible bugs to report after spending a lot of time on the upgrade from 2.04 to 2.05:

After the upgrade, I wound up deleting all of my converted rules and just started over from scratch--there were just too many problems and omissions. But I’m still unclear on the logic of multiple profiles and how they get applied. If one profile is set as the default--with no user groups defined, so it should apply to all groups--then how exactly is another profile assigned to just one user group supposed to over-ride the default behavior? For the resource/create and resource/update sets all the rules for field visibility, labels, values, tabs, and template variables are of course duplicated. So which profile is dominant? In some cases, such as when template variables have been moved to a new tab, if the settings are identical in both the default profile as well as the "over-ride" profile, then I found that the TV’s are not moved at all for that user. This suggests there’s some toggling behavior with some rules, where one profile turns it on and the other winds up turning it off.

Ultimately I had to set up one profile per user group, where each profile is an identical duplicate as far as the sets and rules contained. This means that if I make any changes I have to apply the exact changes in each profile. I really tried several ways to get this to work properly with one default profile that gets over-ridden by other profiles for each user group...but simply could not get things working consistently as I expected.

An important thing to note is that for most form customization rules under resource/update and resource/create, the user group must be granted the access_permissions permission. If not, the rules are not applied. This certainly should be noted in the documentation. But the problem with this is that granting access_permissions gives the user a lot more control than may be safe. I say more about this in a related posting on Access Policies.

What may be the biggest concern is how long it takes for the FC rules to be applied. It’s always been slow--the user could catch a glimpse of the default form before the customizations popped in. But now it’s really problematic; the default form will appear for at least a full second or more on some systems before the customizations take over. As a result of this I may be forced to circumvent Form Customization altogether and attempt to edit the core files instead. That’s really, really unfortunate and I do hope that a way to speed up the application of FC Rules can be found.

And now for what I think are just some bugs:

1) I have one profile where I am turning off almost all fields in the resource/update and resource/create actions. However, the cachable field still displays in both instances. And not a bug, but it would be nice to be able to turn off the ID field as well; that’s not an option offered.

2) Resources that are set to Hide from Menus appear to be immune to nearly all FC rules.


For the bugs, here is my environment info:

MODx 2.0.5-pl Traditional
Linux 2.6.34.6
PHP 5.2.14
MySQL Client 5.1.52
MySQL Server 5.1.52
pdo_mysql 5.1.52

Quote from: SBM at Dec 15, 2010, 02:52 PM

After the upgrade, I wound up deleting all of my converted rules and just started over from scratch--there were just too many problems and omissions. But I’m still unclear on the logic of multiple profiles and how they get applied. If one profile is set as the default--with no user groups defined, so it should apply to all groups--then how exactly is another profile assigned to just one user group supposed to over-ride the default behavior? For the resource/create and resource/update sets all the rules for field visibility, labels, values, tabs, and template variables are of course duplicated. So which profile is dominant? In some cases, such as when template variables have been moved to a new tab, if the settings are identical in both the default profile as well as the "over-ride" profile, then I found that the TV’s are not moved at all for that user. This suggests there’s some toggling behavior with some rules, where one profile turns it on and the other winds up turning it off.

We’ll definitely be improving OOE (order of execution) with FC come 2.2, and dealing with the massive complexities that Form Customization brings. Maybe you could file a bug report with your setup so that we can further debug the issue?

[qupte]
An important thing to note is that for most form customization rules under resource/update and resource/create, the user group must be granted the access_permissions permission. If not, the rules are not applied. This certainly should be noted in the documentation. But the problem with this is that granting access_permissions gives the user a lot more control than may be safe. I say more about this in a related posting on Access Policies. I can’t replicate this behavior *at all*. I have a user that definitely does not have access_permissions, and they get the FC rules just fine. There’s also no reference in the code anywhere to the access_permission key, so I’m not sure how you got this.

What may be the biggest concern is how long it takes for the FC rules to be applied. It’s always been slow--the user could catch a glimpse of the default form before the customizations popped in. But now it’s really problematic; the default form will appear for at least a full second or more on some systems before the customizations take over. As a result of this I may be forced to circumvent Form Customization altogether and attempt to edit the core files instead. That’s really, really unfortunate and I do hope that a way to speed up the application of FC Rules can be found.

Well, that’s mainly because of Template Variables; since they load post-facto via AJAX (to allow for changing the Template to change the TVs; that and the forms are generated by ExtJS - so they can’t be "pre-filtered". We’ll probably improve this quite a bit in future releases and try and nuke that lag.

And now for what I think are just some bugs:
1) I have one profile where I am turning off almost all fields in the resource/update and resource/create actions. However, the cachable field still displays in both instances. And not a bug, but it would be nice to be able to turn off the ID field as well; that’s not an option offered.

That is fixed in upcoming 2.0.6: http://bugs.modx.com/issues/3082

2) Resources that are set to Hide from Menus appear to be immune to nearly all FC rules.

Probably due to the bug where FC doesn’t fire on Resources without a Template: http://bugs.modx.com/issues/3083

I can’t reproduce a hidemenu checked bug, though.

Thanks for your response!

Regarding the situation where I found access_permissions required:

I have a fairly complex resource/update rule that turns off most default fields, renames a few of them, turns off a tab, adds a tab, renames the tabs, and moves some tv’s to the new tab. Out of all of that and a good bit of testing, it came down to just one thing: renaming the modx-resource-access-permissions tab is the culprit. Even if that tab is turned off for the targeted user group, as long as it has been renamed then they will have to have the access_permissions right assigned or nearly everything in the rule will fail. So it looks like this is a bug more than anything else.

And you are absolutely correct about my hidemenu problem; it was actually the empty template bug.

Can you file that access permissions bug here: http://bugs.modx.com/ so we get it fixed before 2.1?

Thanks for your investigative work. Mucho helpful.