Warning if Editable or Enabled is set on page group level

[jwikman]

The Editable and Enabled properties on pages should be set on field level only and not on group level, according to Yammer thread https://www.yammer.com/dynamicsnavdev/threads/1508881289134080

A new rule that warned when the Editable or Enabled property is set on a group would help us identify all those pages that are affected.

[rvanbekkum]

One thing I was wondering about: what if Extensible = false for the page in question, then it cannot happen that someone changes where (in which group) the field is placed on a page. Don't get me wrong, I think you'll want to have most of your pages set to Extensible = true, but there are instances where it makes sense to set Extensible = false.
Anyhow, it could be something to consider when implementing a rule for this, e.g., skip the object if Extensible = false.

[jwikman]

Hi @rvanbekkum,

I believe that the user is allowed to personalize the page even if Extensible = false - so I don't think we need to take the Extensible property into consideration for this rule.

Or have you seen that personalization is disabled for some pages?

[rvanbekkum]

Ah, no, of course. I was thinking about the "Design" option in the client. But, of course, it's also already possible to move fields with personalization. 🙈

[jwikman]

This scenario seems to affect the Enabled property as well, I've updated the title and original post with this. (and Yammer)

[StefanMaron]

Okay, so the warning would only show up if either Editable = false or Enabled = false is set on any group level on a page or pageextension, right?

What about Visible = false ? In this case this scenario can not happen as the user can not move fields in a group like this. But the group could be set to visible by a 3rd extension, then a field could be moved by a user and the extension could be uninstalled, leading to the moved field being not visible anymore

[jwikman]

The Visible property works as intended, and it should be set on group level to work properly with a variable.

This rule should only care about Editable and Enabled. And it should be triggered if false or set to a variable.

[StefanMaron]

With a variable, I totally agree. I was talking about a static Visible = false on group level

[jwikman]

With a variable, I totally agree. I was talking about a static Visible = false on group level

If a field has Visible = false, either on itself or on a parent group, it is possible for the user to make the field visible - and that's the whole point with that, or am I mistaken?

[StefanMaron]

I am just trying to verify if visible can also lead to unexpected behavior when user personalisations and multiple extensions modify the same page. But I guess a field, which is not visible, can always be added to page via personalisation, so I guess the "damage" would not be as bad.

Anyways, I think my described scenario still can happen. And I also think, that it would be nice to be consistent here. If enabled and editable should not be set on group level, visible should not be set at group level either.

[jwikman]

The visible property is intended to be changed by the user, and it seems to work just fine. If a user adds a field that is not visible (visible = false on a parent group or on the field itself) it is because they want it to be visible.
The enabled and editable properties is not intended for the user, they should only be changed by code. And the current behavior of the web client could lead to disaster, hence the need for this rule.

So I do not agree that the three of them needs to be handled in the same way.

That being said, I wouldn't bother that much if you implement it in that way, since I don't believe that we are using visible = false on groups at all... ;-)