Jump to content

UserGroups module in development: groups & page based permissions


apeisa

Recommended Posts

PW has very flexible UA management. Most of the sites can get the exact needs fulfilled after little clicking. But when you need to scale it in horizontal way: ie. adding ten different news sections, each with same templates but managed by different group of people, PW doesn't make it too easy (since UA is tied to templates). 

Also roles&permissions&template access is a combination, that at least we cannot leave to our clients (it's way too complicated for your average editor) - it means that UA management have to be done by us. This is fine on small scale, but some of our sites are pretty heavy on UA: biggest site has over 800 user groups and many times we do have something like 50 000 users importet (these sites are not build on pw today, but hopefully they will be). So we need to have simpler UA that our clients understands and can use on daily basis. That will also mean less granular control, but easier to manage.

Lucky for us, PW has hook system in place, that is flexible enough to allow hooking to UA also. Few months ago I started building module to add two features for PW:

-user groups (user can belong to more than one group)

-page based permissions based on groups (so you can say: this page and it's children can be edited by groups A + B and viewed by groups A + B + C

I first thought that I should release this as a paid module, but after showing this current early version to Nik and Teppo (I knew they had similar needs) and when they showed interest in development  I wanted to make this a community project (this is gonna be thousand times better than just me building it alone). So lot's of progress is coming and of course everyone is invited to collaborate. Be it ideas, comments, testing, use cases etc.

  • Like 21
Link to comment
Share on other sites

Antti, were you able to find a way around the circular page reference limitation in PW? I've still got on my list to find a solution for this, so was curious if you'd found another route to make it work?

Link to comment
Share on other sites

nope, still counting on you with that one. Since it fails only on certain situations, I am pretty confident we do find some workaround.

Pete, should work already. Look that you have both modules installed. Not sure how it went, but it might be that you need to add the created fields to templates manually... (not at computer right now)

Link to comment
Share on other sites

ooh, okay this is interesting since this is something I have played with in various systems.

I like to look at this sort of system in the following ways:

1. Departmental - this is where you divide the data up into departments of responsibilities.

In a company this might be "HR" "Sales" "R&D" and so on

In a newspaper this could be "Sport" "Politics" "Movies" and so on

In a shop it could be "Womens clothing," "mens" etc.

So a User can belong to one or more departments. They can only have permissions of any sort within a department they are part of.

Some systems make departments hierarchical, but this can be problematical and you can end up switching off permissions rather than switching them on. So, really it is better to keep these isolated.

2. Global Roles

These are the roles that already exist in PW and are applied globally, throughout departments. In a complicated site, these are not much used as it is better to work within departments.

3. Local Roles

These are roles specific to one department only

So you might be an editor in one department, but only a dishwasher in another!

4. User Groups - these can work horizontally across departments. So for instance, A user group might have three departments associated with it. Any member of that user group is then automatically a member of those departments. 

5. Page Roles

This last is exceptional and is where a specific user may need access to a specific page that is not covered by their existing permissions structure. This access could be given exceptionally to either a single user or a single group. 

This looks very heavy, but in reality it makes just about anything possible and once it is set up for a particular site, can make the day-to-day operation manageable.

Link to comment
Share on other sites

Joss, that looks like "the ultimate solution". I think we are aiming for something little bit more simpler, but altogether flexible system.

I am thinking whether we should have groups inside a group (sometimes these are a real lifesaver, but they also make things more complex for many)? Also thinking about "group admin", that could create new users into the group(s) they manage (also manage users, if they are admin on each group where user belongs).

Link to comment
Share on other sites

Nik figured nice and simple workaround here: https://github.com/a...commit/46161510

Nice job Nik! Does that mean I don't have to figure out how to solve circular Page references in the core, or do we still need that? What's funny is that I was working on this in the core a couple of hours ago and then got a forum notification email that Nik had found a workaround. But I can keep working to find a core-level solution if we still need it. 

Link to comment
Share on other sites

Apeisa - yes, it is a bit of an overwhelming solution, but the point is that it has structural merit, even if not all of it is adopted.

With groups, yes, you should have internal structures.

In liferay, they have certain built in roles that can just be applied to an organisation or site (or a group in your case).

So, you would have Admin, Manager, Moderator, User, Guest roles that only work within a specific group. You would give these some logical default permissions so that people can use these out of the box, but the roles can also be edited or new roles created. 

I don't actually like the way they name them - it makes everything sound like a techy forum, and I suspect that puts some clients off. I would rather that they either reflected the hierarchy of a publishing house (Managing Editor, Editor, Sub Editor, Writer) for some uses or a standard company structure for others. But that is just me and names can easily be changed!

Adding the idea of scope to your system covers all of this of course - if you can define scope for a particular role (global, group, whatever) then that allows a huge amount of variation. So a role would have Group scope - that means it only applies in the context of a group. It also has a flag to define WHICH group it specifically applies to. 

As for groups within groups, I think that would blow most peoples heads off as the normal way of structuring a PW installation does not demand it.

However, if in the future you are running multiple installations, then this comes into play. So, for instance, the over-arching installation would have permissions covering all groups, but groups can install unique installations of PW (running on the same database), and these installations can in turn have their own groups. But lets not go there yet!

Link to comment
Share on other sites

Ryan, I don't see need for it, at least not because of this module. Solution we have now should work as good as the earlier (I am bit disappointed that I didn't invented that, since it isn't codin magic, but plain old selectors...).

  • Like 1
Link to comment
Share on other sites

Nice job Nik! Does that mean I don't have to figure out how to solve circular Page references in the core, or do we still need that? What's funny is that I was working on this in the core a couple of hours ago and then got a forum notification email that Nik had found a workaround. But I can keep working to find a core-level solution if we still need it.

Ryan, I don't see need for it, at least not because of this module. Solution we have now should work as good as the earlier (I am bit disappointed that I didn't invented that, since it isn't codin magic, but plain old selectors...).

Just for the record, similar issues have caused me a lot of headache over last month or so; the more I work with page references, more obvious it becomes that something is broken. Even though there's a way around it here (and usually in other cases too), I really hope that module authors wouldn't have to jump through hoops to achieve something that should be a no-brainer.

Sorry if I sound a bit agitated, but having spent literally hours in my last module to hunt an issue down -- only to find out that it requires what I'd consider an ugly hack to get over -- has that kind of effect on me :)

Link to comment
Share on other sites

Nice job Nik! Does that mean I don't have to figure out how to solve circular Page references in the core, or do we still need that? What's funny is that I was working on this in the core a couple of hours ago and then got a forum notification email that Nik had found a workaround. But I can keep working to find a core-level solution if we still need it. 

Thanks Ryan! And sorry ;).

Like Antti said, the fix isn't needed for this module anymore. Then again, I'm actually working in the same office with Teppo (and few others) and it would really make a difference in our working conditions if you were able to solve this in the core. :D

Seriously speaking, this really seems like something that needs to be fixed. Probably it doesn't need immediate attention and could wait for a while but I do hope you don't just let it be as it is now.

Link to comment
Share on other sites

Apeisa

Just as an offshoot of your user groups ...

It would make sense that if a user group is responsible for only one part of a site, that on the Pages page of the admin, they only see the bits of the site they are responsible for. 

In a very complicated site structure, this would make navigation and administration far more logical and has offers the nice comforting psychological aspect of logging in straight to your area of concern.

There are two ways of displaying this, as far as I can see.

If your group were responsible for a clear branch of the page tree, then "home" would be replaced with the parent where your responsibility lay,

However, if you belong to more than one group or if your group is responsible for more than one branch, then your display of pages would have to start at the highest common point to cover all those trees.

Alternatively, (and I think this would look less messy) you would display the list of parents for each branch (or point down the branch) for which that group is responsible.

So, these parents would be listed artificially at the same level, even though in reality, they may be all over the place in the hierarchy.

This would need to be an optional system (perhaps an extra module) since in a simpler site it may be preferable to lay everything out logically and just not have some sections accessible to some groups/people

Link to comment
Share on other sites

Regarding circular references with pages, ProcessWire was never intended to allow them. The code was already written to prevent them from occurring, per a GitHub issue that came up a few months ago. When I found out Antti's module needed them, I held off on committing those updates to make sure we could find a solution that worked with his module. So what I'm trying to determine is just if I can now go ahead and commit those updates that disallow circular page references, or if someone has a real need for them that can't be solved any other way. I have never understood the need for a circular page reference, and am not sure if they are even a good idea in any case. But if you guys have a need for circular page references, please let me know before I put the code back in place to keep them from occurring. 

Link to comment
Share on other sites

@ryan: I'm not 100% sure that we're talking about same issue here, though I thought they would be related as symptoms are practically identical. Previous case where this happened was when page A had field that referenced page B.. which had a field that referenced page A.

With page fields (strictly speaking fields where the value is instance of Wire) change tracking does something I can't quite grasp -- instead of answering the question "has field value changed", it seems to check if object that field references has changes. Different kind of circular reference issue, perhaps? :)

Just to be very clear: apart from what this module was doing earlier, I've never had/seen any reason why page should be able to reference itself.

Link to comment
Share on other sites

It would make sense that if a user group is responsible for only one part of a site, that on the Pages page of the admin, they only see the bits of the site they are responsible for. 

In a very complicated site structure, this would make navigation and administration far more logical and has offers the nice comforting psychological aspect of logging in straight to your area of concern.

Agreed -- and I'd like to add that in some cases even the page names and/or titles themselves could be considered confidential data. I'm thinking about things like closed intranet for managers, working group discussions etc.

  • Like 1
Link to comment
Share on other sites

One thing I think is important is that all of this advanced back-office functionality needs to be modular - for most sites out there none of this is needed, but for those that benefit from this level of complex management, offering a full solution is quite a game changer.



Just to be very clear: apart from what this module was doing earlier, I've never had/seen any reason why page should be able to reference itself.

Hey, I talk to myself all the time - or is that not the same problem??

  • Like 4
Link to comment
Share on other sites

Joss, it's pretty much like that. Also the topic of the discussion is you.

On a sidenote, Nik and Teppo are on fire with the module. My job seems to be pressing those green merge buttons on github. I like it this way ;)

  • Like 6
Link to comment
Share on other sites

On a sidenote, Nik and Teppo are on fire with the module. My job seems to be pressing those green merge buttons on github. I like it this way ;)

I have to say it's been fun working with this module. And at the same time quite weird as I'm not used to writing open source code during the daytime. :D

Still some work left until it's truly ready for production use but it looks like we're getting there. Just keep on pushing those green buttons, we'll handle the rest!

  • Like 6
Link to comment
Share on other sites

  • 3 months later...

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.
×
×
  • Create New...