It is not possible to allow users to Edit nodes only (role permissions are bypassed)

Created on 24 July 2024, 3 months ago
Updated 15 August 2024, 2 months ago

Problem/Motivation

First off, great module and extremely useful for the management of content access!

By default the module provides edit and delete access to all paths provided. Even if a site builder specifies that a role should only have edit access from the Drupal Permissions screen, he/she can still delete a node when a Content Access Path is assigned to them. This isn't immediately obvious to site builders and could lead to confusion.

I believe Content Access By Path should respect the options set on the Permissions screen. This would also allow more complex use cases that require finer grained control over node access. For example, perhaps an HR department can only edit nodes already created by Communications.

Steps to reproduce

  • Assign access to only edit a specific content to a Drupal role via the Permissions screen;
  • Create a new Content By Path taxonomy term for a specific path (where content is already present on the site);
  • Assign the Content By Path taxonomy term created to a test user;
  • Log in using the test user's account and navigate to the path containing content. You will notice that you can edit as well as delete a node even though the role is technically not allowed to delete content as specified on the Permissions screen.

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Fixed

Version

1.0

Component

Code

Created by

🇨🇦Canada joelseguin Ontario, Canada

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @joelseguin
  • Issue was unassigned.
  • 🇮🇪Ireland markconroy

    Thanks for posting this @joelseguin. I'll work on a fix for it.

    ---
    Thanks to Code Enigma for sponsoring my time to work on this.

  • Merge request !8Resolve #3463597 "Permissions check" → (Merged) created by markconroy
  • Status changed to Needs review 3 months ago
  • 🇮🇪Ireland markconroy

    Hi @joelseguin

    I have a merge request ready for this. Can you test it please?

    https://git.drupalcode.org/project/content_access_by_path/-/merge_reques...

    The only file you need to look at is the changes in the .module file. All the other changes are just coding standards fixes.

    Thanks very much.

    ---
    Thanks to Code Enigma for sponsoring my time to work on this.

  • 🇨🇦Canada joelseguin Ontario, Canada

    @MarkConroy

    I've applied the patch to my test site and it works great!

    I've tested against a few different scenarios and it is working as I would expect. I even tried adding a content type that my test user does not have edit/delete permissions and it could only be seen in the content list (view only).

    The one thing I did notice was that if this patch gets merged it would be an important change in how the module works with permissions.

    • For existing sites that have not assigned specific content type permissions to roles, then those roles would lose access to modify/delete altogether. I've tested this out and it is the case.
    • It should probably be mentioned that after updating the module, site builders should go back and verify the content type permissions since content access will likely be different following the update.
    • For new users of the module, it might also be helpful to provide a reminder on the Content Access By Path taxonomy term form display. For example: Make sure to provide the necessary permissions to content types as well.
  • Status changed to Fixed 3 months ago
  • 🇮🇪Ireland markconroy

    Thanks @joelseguin I have this merged now.

    I think this approach is the correct approach, so there is a double layer before you can edit things

    - it must be in the path you are allowed edit and
    - you must have the correct permissions to edit it

    This means if you have a node of type event inside this path but are not allowed to edit events, we catch that.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024