When trying to narrow down editory rights for Fieldable panel panes, the revision rights (create, edit and delete a revision) are linked to both the 'delete' and 'administer' panels pane right. In practice one would want them to be seperate so more fine-tuned settings would be available.

For instance now it not possible to let a user change the revision of the pane but not let them delete the pane. Or am I missing a setting?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

That's odd. What, specifically, is linked to the delete right, do you know?

Argus’s picture

Besides the delete right also the revision right (@ admin/structure/panels/entity/view/%/revision): where all the revision actions are available: display, edit, delete, make current.

merlinofchaos’s picture

Okay so the revision list is attached to the 'administer' permission. It has nothing to do with 'delete', and I can't find anywhere in the code that it might be. Unless you mean that 'administer' includes 'delete' which is typical of an administer permission?

Argus’s picture

I attached a screenshot from the /admin/people/permissions page. With these settings the authenticated user (middle row) can change the revisions. When I disable the "Delete Panels pane" checkmark, the authenticated user cannot change the revisions.

The "Administer fieldable panels panes" setting also gives this permission.

merlinofchaos’s picture

Category: feature » bug

Okay, I see what I did. I think the menu item must've been cut & pasted from delete.

So the real question is, what flag should that actually be. Need to check node and see what it does.

merlinofchaos’s picture

Ok, node.module has an overall 'view revisions', 'revert revisions' and 'delete revisions' that is global. I could duplicate that, but I'm wondering if I should make it per bundle type.

Argus’s picture

It is feasible that a different bundle type could require different permissions. That would give us a very fine grained access policy. So yes imho.

awebb’s picture

I would definitely be in favor of the granular bundle permissions myself.

Jason Dean’s picture

I'm just getting my head around this, but noticed that 'create new revision' seems selected by default.

My site doesn't use revisions so I want user to be able to deselect, which requires the 'Administer fieldable panels panes' permission. But I don't want them to be able to delete.

merlinofchaos’s picture

The simplest thing to do is implement hook_form_alter and change the #default_value of that flag to 0.

dajjen’s picture

Issue summary: View changes

Hi I'm also interested in this functionality. Has anyone a patch for this?

DamienMcKenna’s picture

I would favor having a generic set of revisions permissions but using them in tandem with the other CRUD permissions to identify the user's access.

ron_s’s picture

I've found a bug related to this issue. In hook_menu, the Revisions menu item (admin/structure/fieldable-panels-panes/view/%fieldable_panels_panes/revision) is displayed if a user has the Delete permission for a given FPP entity, but throws a WSOD if the user clicks the menu item and does not have "administer fieldable panel panes."

ron_s’s picture

Component: Miscellaneous » Code
Status: Active » Needs review
FileSize
9.33 KB

Here's a first pass at creating a generic set of revisions permissions, in tandem with existing FPP entity access. Let me know your feedback, thanks.

ron_s’s picture

Attached is an update to #14. It includes a function to assign "view fieldable panels panes revisions" to all roles with "administer fieldable panels panes."

My preference would be to have the fieldable_pane_entity_revisions view permission use conditional logic, but obviously this is not possible. The next best option is to give it the "view fieldable panels panes revisions" perm, and make sure each admin role has the same perm.

If we wanted to take this one step further, could make "view fieldable panels panes revisions" selected and disabled if "administer fieldable panels panes" is set. I don't know how else we can avoid the WSOD.

DamienMcKenna’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

This sounds good, but I think we need to add some tests to confirm what should happen.

ron_s’s picture

Damien, thanks for the feedback. Anyone available to help write some tests? I'm super busy at the moment.

Attached is an update to #15. Only change is modifying the .install update from 7115 to 7117. This accounts for the new 7.x-1.11 release.

ron_s’s picture

After reviewing patch #16 on Issue #2390145 (https://www.drupal.org/node/2390145#comment-11633601), it seems as though there needs to be some additional coordination.

Both patches modify the same code, but for different reasons.