Jump to content

Module: Page Edit Per User


ryan
 Share

Recommended Posts

Assign edit access to individual users on a per-page basis

The user must already have page-edit permission on one of their roles in order to get edit access to assigned pages. Otherwise, they will only gain view access.

This module is fully functional as-is, but intended as a proof-of-concept for those wanting to go further with adding custom edit and/or view access. The main functionality in this module consists of only a few lines of code, so it should be a simple edit for anyone wanting to take it further. If you make some useful additions to it, please post them.

How to use

  1. Create a new role called "editor" (or whatever you want to call it) and give the role "page-edit" permission. If you already have a role in place that you want to use, that is fine too.
  2. Under "Access > Users" locate the user you want to assign edit access to. Edit this user.
  3. For this user's "Roles" field: choose the new role you added, "editor" (or whatever you called it).
  4. For this user's "Editable Pages" field: select one or more pages you want them to be able to edit.
  5. Save the user and you are done.

To test, login as the user you edited to confirm it works how you expect.

http://modules.processwire.com/modules/page-edit-per-user/

https://github.com/ryancramerdesign/PageEditPerUser

  • Like 10
Link to comment
Share on other sites

Don't give me too much credit guys. I've got all of 15 minutes invested in this particular module, and most of that was writing the instructions. :) But the subject came up on another thread and just wanted to have a proof-of-concept of how simple it is to plugin your own hooks to customize user access in any way you want.

Link to comment
Share on other sites

This is a nice example of using hooks. Tomorrow gonna see what is going on with the line: "$this->user->editable_pages->has($event->object);" as I don't understand it right now.

One point.

Why don't you use: $this->message($this->_("Added field 'editable_pages' to the user template.")); etc...

Link to comment
Share on other sites

This is a nice example of using hooks. Tomorrow gonna see what is going on with the line: "$this->user->editable_pages->has($event->object);" as I don't understand it right now.

Here is the same thing rewritten to be more verbose.

$user = $this->user; // current user
$page = $event->object; // page where editable(); function was called
$user->editable_pages->has($page)) {
 // user's editable_pages field has $page in it
 // so we set the editable(); function's return value to true,
 // which means: "yes give them edit access"
 $event->return = true; 
}

Why don't you use: $this->message($this->_("Added field 'editable_pages' to the user template."));

I should, but sometimes forget since I don't often use the multi-language features myself. I will update the module.

  • Like 1
Link to comment
Share on other sites

Don't give me too much credit guys. I've got all of 15 minutes invested in this particular module, and most of that was writing the instructions. :) But the subject came up on another thread and just wanted to have a proof-of-concept of how simple it is to plugin your own hooks to customize user access in any way you want.

Ryan,

This is possible because of how you designed Processwire, so the credit is well deserved. :)

Great module BTW, I can really use this.

Link to comment
Share on other sites

@soma: At least I used your solution from that very thread as I happened to need something very similar the next week you had shared it. Not that it would necessarily make you feel any better, but just wanted to tell that you were acknowledged back then :).

Anyway, clever usage of what ProcessWire makes possible, from the both of you.

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Well, I just submitted a pull request for this module that might be of use to others here. It adds the ability to check to see if parent pages appear in a user's editable-pages list and to allow editing if that's the case. This allows marking whole branches of the page tree as being editable by a user with just the addition of the root page to the user's list.

  • Like 2
Link to comment
Share on other sites

  • 1 year later...

Is there a simple (explained for PHP-Newbies) way to edit this, so that users can add children to pages for which they have access.

I've already read this thread but I am not sure what I have to do exactly.

My plan is to have a user "user-a" who has the permission to edit the page "home > user-a" and also has the ability to add pages of the template "year" to this page, but ONLY to this page.

The situation now is like: user-a can edit page "home > user-a"  a module I found on the forum has created some subpages for him and user-a is able to edit those pages too, but has no "add"-ability (which is good for me). 

Thank you,
Tommy

Link to comment
Share on other sites

  • 1 month later...

Awesome module.  Is it possible to set things up such that when a user logs in they don't see the whole tree, just the pages they're allowed to edit?

Bump... any ideas on this?

I don't think there are any 'ready to go' solutions for this, mainly because hiding non-editable pages in a tree based hierarchy can be problematic. I'm digging up a quite old -but still relevant i think- thread with also some contributions from Ryan. https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/

If this is really needed i'm wondering if it wouldn't make more sense to keep such users out of the pages tree all together, and instead build a custom page where they can view everything the are allowed to, and nothing more. https://processwire.com/talk/topic/6142-hide-page-tree-in-the-admin/

Maybe someone else has some new insights on this subject.

  • Like 2
Link to comment
Share on other sites

Thank you for responding.  Wanze's code in the second link looks like just what I need but I'm puzzled a bit about where it goes. I have left a question on that thread and in the meantime I'll do a bit of experimenting to see if I can't figure it out on my own.  Thank you again for pointing me to those links.

I don't think there are any 'ready to go' solutions for this, mainly because hiding non-editable pages in a tree based hierarchy can be problematic. I'm digging up a quite old -but still relevant i think- thread with also some contributions from Ryan. https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/

If this is really needed i'm wondering if it wouldn't make more sense to keep such users out of the pages tree all together, and instead build a custom page where they can view everything the are allowed to, and nothing more. https://processwire.com/talk/topic/6142-hide-page-tree-in-the-admin/

Maybe someone else has some new insights on this subject.

Link to comment
Share on other sites

  • 1 month later...

Maybe someone know how forbid access to edit page if user not author of page. Like deny access for edit if created_users_id != this->user.

Thanks!

Thanks to Soma:

https://processwire.com/talk/topic/3875-module-to-add-userid-to-pages-and-control-edit-permissions/?p=37915

Also check out the revised version a few posts below from pogidude.

And also this version from tinacious:

https://processwire.com/talk/topic/3271-can-i-limit-page-editing-to-the-user-that-created-that-page/?p=32121

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...