Permissions for user to only edit their own pages? Virtual User Group?#

I know this has been discussed before (and sorry that my google-shui sucks because I can't find the links to some previous discussions that I know I bookmarked), but it's an interesting use-case that is worth discussing.

Basically, the desire is this: let a user log in and edit only pages that they themselves have authored. It'd be relatively easy to check this sort of thing if you were building your own editing form: just check the user ID of the currently logged in user, and only let them edit documents where their user is referenced in the createdby column.

I've been scanning through the policy templates, but I don't see anything that covers this. I can of course, create a user group and a resource group, and grant appropriate access between them, but that will get cumbersome when we're potentially considering thousands of users.

What we need is something like a "virtual user group" and a "virtual resource group"... a shorthand way of granting the necessary permissions based on the user id instead of by traditional User Group/Resource Group. Each user may have created a handful of pages, but they'd need the ability to edit them all, and ONLY those pages.

If there's an obvious way of doing this, someone please feel free to smack me upside the head, but right now I'm wondering the best approach. Is there an event that we can tie a plugin to do this type of thing on the fly?

Any ideas are most welcome. Thanks as always.

There are lots of different ways to implement this. There's one in my book that uses a tree_root_id user setting to do this. It's set in a plugin when the user is created, IIRC.

The cleanest implementation, IMO, is to use NewsPublisher in the front end with a snippet at the top of the NewsPublisher page that checks the user ID against the createdby field of the resource and kicks out (forwards?) users who didn't create the current resource. You could also modify the NpEditThisButton snippet to only show the button on pages the user created.

In the Manager, the same strategy could be used in a plugin attached to OnDocFormPrerender.

Another way to go is to use a plugin that responds when a new user is created and automatically creates the user's resource, the user group, the resource group, and the appropriate ACL entry.

Of course you'd probably also want to control what pages the user creates in the first place.

Thanks Bob. I haven't gotten to that part of your book yet... I'll have to investigate that.

I've written code for another site that creates user groups/resource groups, but that's just overly complicated for this, and more importantly, the performance of the manager gets slow when you're dealing with thousands of groups like that (at least it did in 2.1.3).

The users shouldn't be able to see anything other than stuff they created. So I might need to do something more thorough than the NewsPublisher, but I'll have to take a closer look....

Maybe I can do something like this:

Put all the "limited" users into a "Limited Users" user group, then run a plugin that intercepts not only the OnDocFormPrerender event, but also any event that displays the site navigation tree. Or perhaps easier is to customize the manager for the "Limited Users" group so they can't even see the site navigation tree, and then use a CMP to list only the pages that they have access to. They could click each page that they've created (probably only a handful for each user), then fire up the standard editor for editing the page (I could do Form Customization for the "Limited Users" group to ensure that they are only able to edit certain portions of the documents).

The CMP sounds like a good bet.

I got the CMP set up -- it's so great to have your book, Bob -- I can't express enough gratitude for your hard work on that.

So it's easy enough to come up with some links that will let the user edit the page when the link is clicked. Done.

The 2nd part of this is a plugin that fires as the document is being loaded for editing. I've got all the logic in place to verify that the logged in user is the original author of the page he's trying to edit... but what I'm not clear on is how to handle that plugin event to disrupt the edit page from loading... should I just do a redirect to another page and then kill the script? Or is there some better way to do this?

Thanks, as always.