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?

CommentFileSizeAuthor
#17 fieldable_panels_panes-revisions_crud_perms-1528904-17.patch10.1 KBsgdev
#15 fieldable_panels_panes-revisions_crud_perms-1528904-15.patch9.99 KBsgdev
#15 interdiff-1528904-14-15.txt612 bytessgdev
#14 fieldable_panels_panes-revisions_crud_perms-1528904-14.patch9.33 KBsgdev
#4 fieldable panels pane permissions.png73.95 KBArgus

Comments

merlinofchaos’s picture

merlinofchaos commented

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

Argus’s picture

Argus commented

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

merlinofchaos commented

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

Argus commented
StatusFileSize
new fieldable panels pane permissions.png73.95 KB

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

merlinofchaos commented
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

merlinofchaos commented

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

Argus commented

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

awebb commented

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

Jason Dean’s picture

Jason Dean commented

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

merlinofchaos commented

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

dajjen’s picture

dajjen
Location Östersund (Sweden)
commented
Issue summary: View changes

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

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

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.

sgdev’s picture

sgdev commented

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."

sgdev’s picture

sgdev commented
Component: Miscellaneous » Code
Status: Active » Needs review
StatusFileSize
new fieldable_panels_panes-revisions_crud_perms-1528904-14.patch9.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.

sgdev’s picture

sgdev commented
StatusFileSize
new interdiff-1528904-14-15.txt612 bytes
new fieldable_panels_panes-revisions_crud_perms-1528904-15.patch9.99 KB

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

damienmckenna
Location TN, USA
commented
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.

sgdev’s picture

sgdev commented
StatusFileSize
new fieldable_panels_panes-revisions_crud_perms-1528904-17.patch10.1 KB

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.

sgdev’s picture

sgdev commented
Related issues: +#2390145: Security issue. Add access callback for admin views.

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.