Fieldset (Tab): not able to set permissions?

[snck]

Hello,

for a project I have pages with different “content areas“ that can be edited only by specific user roles. In the past I setup a fieldset (tab) containing all the fields that should be available to only one specific group of users and set the fields' view and edit permissions (in the Access tab) accordingly. The result was as expected: Users assigned to the specific role could see the tab, click on it, edit content, users without the role could not see the tab. After updating this installation to 3.0.148 yesterday I wanted to setup another tab following the same principle, but I have no "Access" tab for the fieldset to limit access to the specific role. I even tried cloning an existing (and still working) fieldset. The existing fieldset has some template overrides (screenshot attached) that lead to the desired behaviour, but I am not able to reproduce these settings because there is not "Access" tab for my fieldset in template context either.

Is this a bug in 3.0.148? Has the fieldset fieldtype changed? Am I missing anything here?

I am glad to hear from you guys.
Cheers,
Flo

[Robin S]

5 hours ago, snck said:

After updating this installation to 3.0.148

What version did you update from? I think it hasn't been possible to set access controls on fieldsets for some time, maybe years.

I think there might be a couple of reasons for why you can't set access controls on fieldsets:

1. Edit access (in Page Edit) for a fieldset is meaningless because a fieldset doesn't store any user-editable data.

2. Generally speaking fields do not "know" that they belong to a fieldset. You can run your own logic like this...

...but there is no simple property of a field A that indicates that it is within fieldset B. So setting view/edit access on a fieldset doesn't actually set view/edit access for fields within that fieldset. Back when it was possible to set access controls on a fieldset it might have appeared that there was access control in that maybe the inputfields didn't get rendered, but I doubt that this was proper access control/security on the fields within the fieldset. So my guess is that Ryan removed that option so devs wouldn't get the wrong impression that they are setting access control on fields by setting it on a parent fieldset.

So I think your options are...

1. Set access control on the fields within your fieldset.

2. So long as you know and are comfortable with the fact that it isn't proper access control, you could remove the fieldset using a hook:

$wire->addHookAfter('ProcessPageEdit::buildFormContent', function (HookEvent $event) {
	/* @var InputfieldWrapper $wrapper */
	$wrapper = $event->return;
	// Do some test based on roles
	if($event->wire('user')->hasRole('some_role')) {
		// Remove fieldset
		$fs = $wrapper->getChildByName('your_fieldset_name');
		$wrapper->remove($fs);
	}
});

 

[snck]

Dear @Robin S,

thanks for your explanation! My installation was on 3.0.62 before, but maybe the fieldset has been there even longer. I am doing the access control for my fields with the "Access" tab for the specific fields as well, but I want to hide the fieldsets/tabs for users that are not able to view them (and in the future there might be a lot of them). Your snippet seems to be the perfect starting point for the desired functionality, so thanks again!

Although this might be a rather specific issue, maybe fieldsets could somehow "inherit" properties from the contained fields like "if the user is not allowed to view a single field in this fieldset, he might not see the fieldset/tab as well."? This way one would keep the access logic on field level, but avoid the confusion of showing unpopulated fieldsets/tabs.

Cheers,
Flo