Jump to content

Admin Restrict Branch


Recommended Posts

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.



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.

  • Like 18
  • Thanks 1
Link to comment
Share on other sites

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?


   My Visible Branch

        My Do Not List Branch

           Child 1

           Child 2

       My Visible Child Branch

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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) :)

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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 :)

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 :P

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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!

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

@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?

  • Like 1
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

  • Like 5
Link to comment
Share on other sites

  • 2 weeks later...

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.

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
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Robin S
      This module lets you add some custom menu items to the main admin menu, and you can set the dropdown links dynamically in a hook if needed.
      Sidenote: the module config uses some repeatable/sortable rows for the child link settings, similar to the ProFields Table interface. The data gets saved as JSON in a hidden textarea field. Might be interesting to other module developers?
      Custom Admin Menus
      Adds up to three custom menu items with optional dropdowns to the main admin menu.
      The menu items can link to admin pages, front-end pages, or pages on external websites.
      The links can be set to open in a new browser tab, and child links in the dropdown can be given an icon.
      Requires ProcessWire v3.0.178 or newer.
      Example of menu items

      Module config for the menus

      Link list shown when parent menu item is not given a URL

      Setting child menu items dynamically
      If needed you can set the child menu items dynamically using a hook.
      $wire->addHookAfter('CustomAdminMenus::getMenuChildren', function(HookEvent $event) { // The menu number is the first argument $menu_number = $event->arguments(0); if($menu_number === 1) { $colours = $event->wire()->pages->findRaw('template=colour', ['title', 'url', 'page_icon']); $children = []; foreach($colours as $colour) { // Each child item should be an array with the following keys $children[] = [ 'icon' => $colour['page_icon'], 'label' => $colour['title'], 'url' => $colour['url'], 'newtab' => false, ]; } $event->return = $children; } }); Create multiple levels of flyout menus
      It's also possible to create multiple levels of flyout submenus using a hook.

      For each level a submenu can be defined in a "children" item. Example:
      $wire->addHookAfter('CustomAdminMenus::getMenuChildren', function(HookEvent $event) { // The menu number is the first argument $menu_number = $event->arguments(0); if($menu_number === 1) { $children = [ [ 'icon' => 'adjust', 'label' => 'One', 'url' => '/one/', 'newtab' => false, ], [ 'icon' => 'anchor', 'label' => 'Two', 'url' => '/two/', 'newtab' => false, 'children' => [ [ 'icon' => 'child', 'label' => 'Red', 'url' => '/red/', 'newtab' => false, ], [ 'icon' => 'bullhorn', 'label' => 'Green', 'url' => '/green/', 'newtab' => false, 'children' => [ [ 'icon' => 'wifi', 'label' => 'Small', 'url' => '/small/', 'newtab' => true, ], [ 'icon' => 'codepen', 'label' => 'Medium', 'url' => '/medium/', 'newtab' => false, ], [ 'icon' => 'cogs', 'label' => 'Large', 'url' => '/large/', 'newtab' => false, ], ] ], [ 'icon' => 'futbol-o', 'label' => 'Blue', 'url' => '/blue/', 'newtab' => true, ], ] ], [ 'icon' => 'hand-o-left', 'label' => 'Three', 'url' => '/three/', 'newtab' => false, ], ]; $event->return = $children; } }); Showing/hiding menus according to user role
      You can determine which menu items can be seen by a role by checking the user's role in the hook.
      For example, if a user has or lacks a role you could include different child menu items in the hook return value. Or if you want to conditionally hide a custom menu altogether you can set the return value to false. Example:
      $wire->addHookAfter('CustomAdminMenus::getMenuChildren', function(HookEvent $event) { // The menu number is the first argument $menu_number = $event->arguments(0); $user = $event->wire()->user; // For custom menu number 1... if($menu_number === 1) { // ...if user does not have some particular role... if(!$user->hasRole('foo')) { // ...do not show the menu $event->return = false; } } });  
    • By tcnet
      This module for ProcessWire sends a notification email for each failed login attempt. Similar modules exists already in the module directory of ProcessWire. However, this module is designed to notify, even if specified user doesn't exist.
      The settings for this module are located in the menu Modules=>Configure=>LoginFailNotifier.
      Notification email
      Specifies the email address to which the notification emails should be sent.
        Email subject
      Specifies the subject line for the notification email.
        Post variables
      Specifies the $_POST variables to be included in the notification email. Each variable must be separated by a comma. For example: login_name,login_pass
        Server variables
      Specifies the $_SERVER variables to be included in the notification email. Each variable must be separated by a comma. For example: REMOTE_ADDR,HTTP_USER_AGENT
      Link to ProcessWire module directory:
      Link to github.com:
    • By Fokke
      ProcessWire 3.x markup module for rendering meta tags in HTML document head section. Note that this module is not a full-blown SEO solution, but rather a simple tool for rendering meta tags based on module configuration. Adding custom meta tags is also supported.
      Built-in meta tags
      The following meta tags are supported out-of-the-box:
      Document title consisting of page title and site name Character set Canonical Viewport Description Keywords Hreflang tags Open Graph og:title og:site_name og:type og:url og:description og:image og:image:width og:image:height Twitter meta tags twitter:card twitter:site twitter:creator twitter:title twitter:description twitter:image Facebook meta tags fb:app_id The full documentation with configurable options can be found here: https://github.com/Fokke-/MarkupMetadata
      ProcessWire>=3.0.0 PHP >=7.1 Installation using Composer
      composer require fokke/markup-metadata Manual installation
      Download latest version from https://github.com/Fokke-/MarkupMetadata/archive/master.zip Extract module files to site/modules/MarkupMetadata directory.
    • By m.sieber
      ITRK-Service for ProcessWire
      Module for the automated transfer of imprint, data protection declaration and terms and conditions from IT-Recht Kanzlei to your ProcessWire installation
      What is ITRK Service for ProcessWire?
      ITRK-Service for ProcessWire is a free module for ProcessWire CMS. It provides an interface to the update service of IT-Recht Kanzlei, via which the legal texts of your online presence are automatically updated. In this way, the texts remain legally secure and warning-proof in the long term. Imprint, data protection declaration, revocation and general terms and conditions are currently supported.
      You can find our documentation (in german language) here: https://www.pupit.de/itrk-service-for-processwire/dokumentation/

      Download: https://www.pupit.de/itrk-service-for-processwire/
      Github: https://github.com/pupit-de/pwItrkServiceConnector
    • By LuisM
      Symprowire is a PHP MVC Framework based and built on Symfony using ProcessWire 3.x as DBAL and Service-Provider
      It acts as a Drop-In Replacement Module to handle the Request/Response outside the ProcessWire Admin. Even tough Symfony or any other mature MVC Framework could be intimidating at first, Symprowire tries to abstract Configuration and Symfony Internals away as much as possible to give you a quick start and lift the heavy work for you.
      The main Goal is to give an easy path to follow an MVC Approach during development with ProcessWire and open up the available eco-system.
      You can find the GitHub Repo and more Information here: https://github.com/Luis85/symprowire
      The Symprowire Wiki https://github.com/Luis85/symprowire/wiki How to create a simple Blog with Symprowire https://github.com/Luis85/symprowire/wiki/Symprowire-Blog-Tutorial Last Update
      16.07.2021 // RC 1 v0.6.0 centralized ProcessWire access trough out the Application by wrapping to a Service https://github.com/Luis85/symprowire/releases/tag/v0.6.0-rc-1 Requirements
      PHP ^7.4 Fresh ProcessWire ^3.0.181 with a Blank Profile Composer 2 (v1 should work, not recommended) The usual Symfony Requirements Features
      Twig Dependency Injection Monolog for Symprowire Support for .env YAML Configuration Symfony Console and Console Commands Symfony Webprofiler Full ProcessWire access inside your Controller and Services Webpack Encore support Caveats
      Symfony is no small Framework and will come with a price in terms of Memory Usage and added Overhead. To give you a taste I installed Tracy Debugger alongside to compare ProcessWire profiling with the included Symfony Webprofiler

      So in a fresh install Symprowire would atleast add another 2MB of Memory usage and around 40ms in response time, should be less in production due to the added overhead of the Webprofiler in dev env
  • Create New...