Module Admin Restrict Branch

[adrian]

This module lets you restrict users to a certain branch of the page tree - it can limit editing permissions, as well as the page list view to this branch.

http://modules.processwire.com/modules/admin-restrict-branch/

https://github.com/adrianbj/AdminRestrictBranch

Restricted View

Non-restricted View

Note that this module does not add permissions (unlike how PageEditPerUser and PageEditPerRole work), so the user must have template level permissions to edit the pages in the restricted branch. What this does allow though is giving all users/roles editing access for the home template and allowing that to inherit all the way through the page tree and let this module restrict to specific branches.

As you can see from the screenshots you can specify how to determine the branch to restrict the user to - either via a matched role name, or via a dedicated page select field on the user's profile.

The match role name works like this - if you have a series of branches called: Branch One, Branch Two, etc, users with a role named: branch-one will only have access to Branch One.

You can also decide whether to restrict page tree viewing as well and editing privileges (default) or just editing privileges.

The Branch Exclusions option is important for things like external PageTable parent branches etc.

Main module config settings

User specific branch setting on user profile page

This module came out of my personal needs as well as this discussion: https://processwire.com/talk/topic/11428-project-design-main-shop-hundreds-of-affiliates/

As always, feedback is very welcome.

[kongondo]

Nice one Adrian, thanks! Was hoping to see some screenshots of a restricted view page tree branch

Just to clarify, by branch you mean a parent page and all its descendants? So, in the example tree below, would the green branches be visible and the red ones be invisible to user X whose view has been restricted?

Home

   My Visible Branch

        My Do Not List Branch

           Child 1

           Child 2

       My Visible Child Branch

[adrian]

Sorry about that - I actually already added those screenshots (between you reading and then posting).

It actually works the other way - it limits the users to see just the restricted branch. Take a look at the new screenshots and let me know if it makes sense.

If you want something like you described, my unpublished AdminPageHider works for that except for child page counting issues.

[kongondo]

Ah, it makes sense, thanks.

[adrian]

Lots of iterative changes made throughout the day to fix some bugs, allow front-end editing branch restriction (to work with FREDI and FEEL - thanks to @tpr for his help in figuring these out) and some other improvements. 

I am now running this on a live site - so far so good but I'll leave the Alpha warning for a little longer.

Be sure to grab the latest version and let me know how it works for you.

[teppo]

If you want something like you described, my unpublished AdminPageHider works for that except for child page counting issues.

Hey there! Just wanted to say that if you find a way to solve these issues, this would be very useful. The recent addition of "listable" support for page tree seemed like a great addition, but this issue makes it feel clunky, if not downright broken (in my use cases, anyway)

[adrian]

Hey there! Just wanted to say that if you find a way to solve these issues, this would be very useful. The recent addition of "listable" support for page tree seemed like a great addition, but this issue makes it feel clunky, if not downright broken (in my use cases, anyway)

Hey teppo - I am actually using "listable" in BatchChildEditor for hiding the children of a specific page - it actually seems to work very well for that scenario. It's more complicated when trying to hide the specific page itself, which is why I haven't used it in AdminPageHider yet. Making numChildren hookable would solve that, but I PM'd with Ryan about this and because it is called so often he doesn't think it is a good idea performance-wise. I may revisit the child count issue in AdminPageHider at some point to see if there is an alternate solution - I tried once but I was trying to reduce the numChildren incrementally, but it seems it is only possible to set it to zero - I asked Ryan, but haven't heard back yet - if it worked, this could be a solution. To be honest when I have used AdminPageHider I haven't worried too much about the incorrect child count - for me it has only ever been on Home and even though it stands out to me, I doubt most site editors would even notice It only becomes a real issue if pagination is involved, but I find that rarely happens at the level of pages directly under Home and that is usually the level I am hiding anyways, so it's not an issue.

This new module is suiting my needs very well for one of my current projects as separate clients are responsible for certain branches of the sites - so much easier to restrict viewing and editing rights by parent than messing around with other solutions. Obviously not always appropriate though.

[teppo]

Most prominent issues, I believe, are pagination and the case where all children of specific page are hidden and a weird half-functional opening animation is left in place.

While I agree that most editors won't notice the off-sync child count, some still will, which will lead to more work for me and others managing the site. Sure, it's not much, but little things like that pile up and turn into noticeable overhead in the long run.

I may have to revisit this at some point too, can't remember exact details anymore. While I get that adding performance overhead for a rarely used feature like this is a bad idea, at the moment I also find it very hard to consider this "working as expected". I even thought about altering the tree with JavaScript after it has been rendered, but that's kind of a volatile solution

[adrian]

Most prominent issues, I believe, are pagination and the case where all children of specific page are hidden and a weird half-functional opening animation is left in place.

Just to clarify - not sure if you are talking about "listable" here - I don't think it suffers from those issues - at least not in my experience with it in BCE. This is how I used it: https://github.com/adrianbj/BatchChildEditor/blob/master/BatchChildEditor.module#L201

[teppo]

As far as I can tell, we're talking about the same thing, but from different points of view. In my use case I need to hide specific pages, which can result in all pages being hidden, in which case the issues I've mentioned before come up.

You're hiding all children at once, which is a different thing.. unless I've misunderstood something about your code

On the other hand, if I could do what you do there *in case that all child pages are hidden one-by-one*, that would be a potential solution. I don't think it would work that way though, because of the order things happen in.. unless I actually pre-populated the "hide children" info during page save, or perhaps iterated children on for each page in addition to targeting the pages that should get hidden directly (which might add a lot of overhead).

Looks like I really need to revisit this sometime soon

[teppo]

Additional note: Ryan did mention this issue in GitHub, and he did also mention one potential solution: modifying the find query directly. In my opinion that doesn't change the fact that listable doesn't behave in a manner that one would expect, but it's definitely something to look into.

[adrian]

Additional note: Ryan did mention this issue in GitHub, and he did also mention one potential solution: modifying the find query directly. In my opinion that doesn't change the fact that listable doesn't behave in a manner that one would expect, but it's definitely something to look into.

Maybe we should continue this conversation over on that Github issue - we are getting way off track with what AdminRestrictBranch actually does - it's purpose is actually fairly simple in scope and it turns out quite easy to implement. It's way simpler to restrict a user to view and edit one branch than it is to deal with all the child count and pagination issues of removing selected pages/branches.

[tpr]

When I select a sub-branch as parent, I get "Nesting level too deep - recursive dependency?" error. I have 3 sub-branches and selecting the first is OK, then selecting second or third results in this error.

Changing the line around 162 to

this ("===" instead of "=="):

return $page === $this->user->branch_parent ? true : false;

or this (adding "->id"s):

return $page->id == $this->user->branch_parent->id ? true : false;

seems to solve.

[adrian]

@tpr - I tried to reproduce here, but couldn't trigger it, but probably some combo of levels/page names that you have that I am missing. I applied your fix and committed so hopefully that will take care of it as you suggested.

Thanks for all your help testing!

[tpr]

Thanks, works fine!

It's because of this I guess:

http://php.net/manual/en/language.oop5.object-comparison.php#71623

[bernhard]

hi adrian,

this is great! would it be very complicated to work not only with single pages but an array of branches that can be accessed by the user?

[adrian]

hi adrian,

this is great! would it be very complicated to work not only with single pages but an array of branches that can be accessed by the user?

I had a feeling that questions was going to come up It would be very easy to make it restrict the editing rights for more than one branch.

But it's not so easy to restrict the page list view to multiple branches. This is where you get into issues with incorrect child page counts and subsequent pagination issues. Have a read of this Github issue: https://github.com/ryancramerdesign/ProcessWire/issues/302 and some of the forum posts it links to. As I mentioned above, AdminPageHider () and some of my gists I link to in that thread might be useful, but the child count is still a problem unless you make numChildren() hookable, which it isn't.

I had a fairly unique need for creating this module - one that @tpr also has (). It works great if you have very compartmentalized branches (potentially subsites) in your page tree that are specific to individual users, or teams of clients.

[bernhard]

would be totally ok for me to have the whole tree visible

yeah i know the numchildren issue... i set it to zero in one of my projects as i only need it on the root page and dont need pagination.

[adrian]

would be totally ok for me to have the whole tree visible

Well if that is acceptable in some cases then I could probably make it possible to limit edit access to more than one branch - would just need to disable the visibility restriction to that use case. I'll take a look sometime in the next couple of days to see what I can do.

[adrian]

@BernhardB - just thinking about this a little - what method for matching users to the parents of multiple branches would you want? I think that likely the only option that would work would be the 'Specified Branch Parent' option. I guess you could assign multiple roles with names that match branch parent names, or perhaps the custom php code option could match branch parent names with partial name matching or something, but these two are sounding a bit more convoluted.

Would you mind having a think about how'd like to see this matching work. I am a little worried about overcomplicating this module, but I think the Specified Branch Parent might be an OK option - what would best fit into your workflow / requirements?

[teppo]

Not saying that multiple branch support wouldn't be a cool feature for Admin Restrict Branch, but in case visibility is not an issue and you're looking into ways to restrict permissions per branch, I would also suggest taking a look at UserGroups and Dynamic Roles. The approaches are slightly different, but both modules already provide support for this.

[bernhard]

thank you both adrian and teppo!

i think teppo is right and i will have to test my setup with dynamic roles - no need to invent that wheel again

[adrian]

Thanks teppo - I do think it makes sense to keep this module a little more focused on single branch functionality.

I haven't actually used UserGroups yet so didn't realize it could do that - thanks for the heads up.

@BernardB - if you try out Dynamic Roles, please be aware of this bug: https://github.com/ryancramerdesign/DynamicRoles/issues/14 - I assume I am not the only one that is being affected by this - I provide a simple fix in that first post that you can implement.

[adrian]

Beta release is now available via the modules directory: http://modules.processwire.com/modules/admin-restrict-branch/

Contains a few bug fixes, adherence to Add New permissions, and the ability to restrict the name matching to the restricted branch to a master parent to reduce potential for incorrect matches and also improve matching selector efficiency.

Despite it being released, please still carefully check that your affected users have the permissions and access that you expect and let me know if you have any problems!

[tpr]

Just popped in to say that the module works pretty well. I've set up roles and permissions (which was a huge work), and I could achieve a state where everything is working as it should on the site.

The only glitch I see is that when editing a page (with a restricted branch user), the breadcrumb on the top shows items above the restricted branch too:

Home -> Page1 ->  Page2 (ARB top level) -> Page3 (-> Page4 under edit)

"Home" and "Page1" should not be visible as they are above the restricted branch. Fortunately clicking on them goes to the restricted branch top, so no harm is made. On the top level the breadcrumb is OK.