Jump to content
adrian

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.

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

https://github.com/adrianbj/AdminRestrictBranch

Restricted View

post-985-0-33780200-1448596555_thumb.png

Non-restricted View

post-985-0-03497400-1448596558_thumb.png

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

post-985-0-62726000-1448596512_thumb.png

User specific branch setting on user profile page

post-985-0-00157900-1447975039_thumb.png

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 16

Share this post


Link to post
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?

Home

   My Visible Branch

        My Do Not List Branch

           Child 1

           Child 2

       My Visible Child Branch

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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) :)

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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!

Share this post


Link to post
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?

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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 bernhard
      --- Please use RockFinder3 ---
    • By MoritzLost
      Cacheable Placeholders
      This module allows you to have pieces of dynamic content inside cached output. This aims to solve the common problem of having a mostly cacheable site, but with pieces of dynamic output here and there.  Consider this simple example, where you want to output a custom greeting to the current user:
      <h1>Good morning, <?= ucfirst($user->name) ?></h1> This snippet means you can't use the template cache (at least for logged-in users), because each user has a different name. Even if 99% of your output is static, you can only cache the pieces that you know won't include this personal greeting. A more common example would be CSRF tokens for HTML forms - those need to be unique by definition, so you can't cache the form wholesale.
      This module solves this problem by introducing cacheable placeholders - small placeholder tokens that get replaced during every request. The replacement is done inside a Page::render hook so it runs during every request, even if the response is served from the template cache. So you can use something like this:
      <h1>Good morning, {{{greeting}}}</h1> Replacement tokens are defined with a callback function that produces the appropriate output and added to the module through a simple hook:
      // site/ready.php wire()->addHookAfter('CachePlaceholders::getTokens', function (HookEvent $e) { $tokens = $e->return; $tokens['greeting'] = [ 'callback' => function (array $tokenData) { return ucfirst(wire('user')->name); } ]; $e->return = $tokens; }); Tokens can also include parameters that are parsed and passed to the callback function. There are more fully annotated examples and step-by-step instructions in the README on Github!
      Features
      A simple and fast token parser that calls the appropriate callback and runs automatically. Tokens may include multiple named or positional parameters, as well as multi-value parameters. A manual mode that allows you to replace tokens in custom pieces of cached content (useful if you're using the $cache API). Some built-in tokens for common use-cases: CSRF-Tokens, replacing values from superglobals and producing random hexadecimal strings. The token format is completely customizable, all delimiters can be changed to avoid collisions with existing tag parsers or template languages. Links
      Github Repository & documentation Module directory (pending approval) If you are interested in learning more, the README is very extensive, with more usage examples, code samples and usage instructions!
    • By Craig
      I've been using Fathom Analytics for a while now and on a growing number of sites, so thought it was about time there was a PW module for it.
      WayFathomAnalytics
      WayFathomAnalytics is a group of modules which will allow you to view your Fathom Analytics dashboard in the PW admin panel and (optionally) automatically add and configure the tracking code on front-end pages.
      Links
      GitHub Readme & documentation Download Zip Modules directory Module settings screenshot What is Fathom Analytics?
      Fathom Analytics is a simple, privacy-focused website analytics tool for bloggers and businesses.

      Stop scrolling through pages of reports and collecting gobs of personal data about your visitors, both of which you probably don't need. Fathom is a simple and private website analytics platform that lets you focus on what's important: your business.
      Privacy focused Fast-loading dashboards, all data is on a single screen Easy to get what you need, no training required Unlimited email reports Private or public dashboard sharing Cookie notices not required (it doesn't use cookies or collect personal data) Displays: top content, top referrers, top goals and more
    • By daniels
      This is a lightweight alternative to other newsletter & newsletter-subscription modules.
      You can find the Module in the Modules directory and on Github
      It can subscribe, update, unsubscribe & delete a user in a list in Mailchimp with MailChimp API 3.0. It does not provide any forms or validation, so you can feel free to use your own. To protect your users, it does not save any user data in logs or sends them to an admin.
      This module fits your needs if you...
      ...use Mailchimp as your newsletter / email-automation tool ...want to let users subscribe to your newsletter on your website ...want to use your own form, validation and messages (with or without the wire forms) ...don't want any personal user data saved in any way in your ProcessWire environment (cf. EU data regulation terms) ...like to subscribe, update, unsubscribe or delete users to/from different lists ...like the Mailchimp UI for creating / sending / reviewing email campaigns *I have only tested it with PHP 7.x so far, so use on owners risk
      EDIT:
      Since 0.0.4, instructions and changelog can be found in the README only. You can find it here  🙂
      If you have questions or like to contribute, just post a reply or create an issue or pr on github, thanks!
    • By MoritzLost
      Sorry for the convoluted title. I have a problem with Process modules that define a custom page using the page key through getModuleInfo (as demonstrated in this excellent tutorial by @bernhard). Those pages are created automatically when the module is installed. The problem is that the title of the page only gets set in the current language. That's not a problem if the current language (language of the superuser who is installing the module) is the default language; if it isn't, the Process page is missing a title in the default language. This has the very awkward effect that a user using the backend in the default language (or any other language) will see an empty entry in the setup menu:

      This screenshot comes from my Cache Control module which includes a Process page. Now I realize the description sounds obscure, but for us it's a common setup: We a multiple bilingual sites where the default language is German and the second language is English. While the clients use the CMS in German, as a developer I prefer the English interface, so whenever I install a Process module I get this problem.
      As a module author, is there a way to handle this situation? I guess it would be possible to use post-installation hooks or create the pages manually, but I very much prefer the declarative approach. The page title is already translatable (through the __ function), but of course at the time of installation there is no translation, and as far as I'm aware it's not possible to ship translations with a module so they are used automatically. Could this situation be handled better in the core? I would prefer if the module installation process would always set the title of the Process page in the default language, instead of the language of the current user.
×
×
  • Create New...