How to show only certain menu items based on security role?

Jan 21, 2011 at 9:31 AM

I plan to use Orchard as a CMS to my websites.

However I do not want clients full access to the CMS.

How can I make it so that certain users in roles can only see certain menu items?

Coordinator
Jan 21, 2011 at 6:41 PM

Go to the Roles screen in the admin and click edit next to the group you want to restrict (you can create your own or give your clients one of the predefined roles). You can then choose what permissions they have. The menu will be trimmed for what they are allowed to do.

Jan 30, 2011 at 8:23 PM
bertrandleroy wrote:

Go to the Roles screen in the admin and click edit next to the group you want to restrict (you can create your own or give your clients one of the predefined roles). You can then choose what permissions they have. The menu will be trimmed for what they are allowed to do.

I have the same issue.  Creating a new role doesn't help as the only permissions are for changing stuff, and not for viewing.  Eg, Ive created a Project content type that I only want some users to see.  There is a page called Projects that shows a list.  This page should only be visible to some users, and projects and the Projects page can only be edited by me (the admin).

 

 

Coordinator
Jan 31, 2011 at 7:21 PM

Ah so you mean on the front-end? There is at least one module currently in development to enable that scenario.

Feb 3, 2011 at 10:25 AM
bertrandleroy wrote:

Ah so you mean on the front-end? There is at least one module currently in development to enable that scenario.

Hi there, I'm currently in the process of starting work with another forum user to do a module that does this.

I would be interested to know more about the other module to ensure we arent trying to do the same thing.

 

cheers,

Nick

Feb 3, 2011 at 6:31 PM
Edited Feb 3, 2011 at 6:32 PM

In my case it's a fairly simple security trimming requirement.  For my personal site I want to have a page of projects Ive been involved in so prospective clients can review my work - but I don't want to broadcast this to the entire world.  It needs to be trimmed server side so this could be set at the page level, list item level or via navigation I guess.  

Cheers

Apr 17, 2011 at 6:20 PM

Does anyone have an update on this?

Apr 17, 2011 at 7:51 PM
Edited Apr 17, 2011 at 7:51 PM

Hadn't seen this thread before; but there's a problem here that I've come up against myself - I raised a workitem: http://orchard.codeplex.com/workitem/17667

Basically there's no way with the built-in content system to restrict viewing of content in any way.

The only place where it's possible is for some reason with blog posts, it happens in the blog post item controller and nowhere else.

I'm working on a module that will enable applying editing permissions per item but I still can't apply view permissions without that workitem being addressed.

However; if all you wanted to do was restrict the menu and didn't care whether anyone can view the items with the right Url (as in Jonesie's requirement), there are a few different approaches you could take.

It might also be possible to do a certain amount with a custom controller for certain types of items and/or some kind of IAuthorizationFilter; but since it's not in my own immediate needs I haven't looked too far into it (would just have been an easy by product of some other authorization work I was doing, if it wasn't for the above issue)

Apr 17, 2011 at 9:19 PM

Bertrand: Perhaps you could share a little more about what you had in mind when you stated: "Shouldn't be too much work actually." Last August in this post: http://social.msdn.microsoft.com/Forums/en/orchardsupport/thread/71b52996-e8ab-4e48-bec1-4365b586e55c

I do have a website with content that needs to be protected, so for me this is a "must have" feature.

Coordinator
Apr 18, 2011 at 7:53 PM

You could implement that as a part. The admin would get a list of roles for the current content item. You would then hook to some event and filter this. The hard part might be in the navigation part. Anyway, Piotr I believe had started something. Maybe ask him?

Apr 20, 2011 at 1:44 PM

Bertrand - what kind of event are you suggesting hooking into here? Having looked at the authorization system there's no "view" permission that gets tested; so I'm not sure where I could best filter it (if there was a "view" permission it'd be easy to implement DynamicPermissions for different content types, as all the various editing permissions already work).

I'm considering a possibility of doing something in the shape table, but the best that could be done there would be displaying "You are not authorized to view this" instead of the shape; couldn't redirect to login as per other types of authentication.

Another possibility might be an IResultFilter; but I'm not sure how reliably I can extract details about the content shape(s) being displayed.

Apr 20, 2011 at 2:13 PM

For many scenarios flexible view/edit permission are critical. Looks like currently Orchard is targeted for admin/autor who create public websites (e.g.: blog). The problems start when somebody wants to create community/workgroup/privet content repository. I think all CMS are facing that kind of issues in some point of development. Even for content creation role based permissions are too weak and user /user group level is needed. For sharing content I think Facebook is good example what need to be done as minimum (but even they model has shortcoming). I would be really good if comprehensive permission system is provided in Orchard core. If permissions are not done right and in the core this issue will surface in every more sophisticated scenario. (Just my 2 cents)

Apr 20, 2011 at 2:38 PM

Yep. These issues matter to me for various reasons.

Although I think most of it can be done in a modular fashion and such complexity in permissions probably isn't needed in Core, since the most common use case is just a single blog owner.

Things like group and per-user permissions over individual items are something I've already started working on (utilising the Relationships module which I've told you about elsewhere).

That's fine for assigning editors and moderators over specific content. But it all comes back to this issue of not being able to restrict normal viewing of content.

Actually, it wouldn't be really too hard to go through all the itemcontrollers in the various core modules and add an authorization check each time content is viewed. I just have other priorities - for instance a certain media framework ;) - but I'll do this myself eventually (or maybe just the shape table based approach I mentioned)

Apr 20, 2011 at 2:41 PM

The issue for me as that if I use Orchard as a CMS and I give a paying client access to Orchard, I potentially do not want them to have full access to Orchard's functionality.  They may also want only certain members of their company to only have editing rights to certain pages of the website.

At the moment both scenarios I believe are not catered for

Apr 20, 2011 at 3:02 PM
Edited Apr 20, 2011 at 3:03 PM

jchannon, I'm in the same situation. I've already implemented proper user management rights on a separate fork, meaning an admin user can manage other user accounts without having access to everything else. I'm hoping this can eventually make its way into core as it seems to me a fairly common use case (and was far from ideal to implement as a separate module). I detail more about that in this thread: http://orchard.codeplex.com/discussions/253592  ... it's entirely working, but there are some comments there on what still needs to be done in terms of automated testing (which would be essential before I'd even suggest it be included in core).

As it stands there are already ways to give only certain users editing rights for certain pages. You just need to create different Content Types for the different permission levels of pages; then in the Roles setup you can control editing permissions per content type for different roles. So you can definitely achieve this, it's just a bit awkward, and certainly not as direct as "user A can edit content item B". That's what I'm trying to cater for in a separate module, and I've already got that working - it just needs some interface improvements to be really usable.

The scenario that still appears to be extremely difficult without core modifications is "private viewing content" but perhaps with some more investigation and/or a resolution to http://orchard.codeplex.com/workitem/17667 it'll also be possible.

Apr 20, 2011 at 3:20 PM
randompete wrote:

Yep. These issues matter to me for various reasons.

Although I think most of it can be done in a modular fashion and such complexity in permissions probably isn't needed in Core, since the most common use case is just a single blog owner.

Things like group and per-user permissions over individual items are something I've already started working on (utilising the Relationships module which I've told you about elsewhere).

That's fine for assigning editors and moderators over specific content. But it all comes back to this issue of not being able to restrict normal viewing of content.

Actually, it wouldn't be really too hard to go through all the itemcontrollers in the various core modules and add an authorization check each time content is viewed. I just have other priorities - for instance a certain media framework ;) - but I'll do this myself eventually (or maybe just the shape table based approach I mentioned)

I can't really agree with you here that "complexity in permissions probably isn't needed in Core, since the most common use case is just a single blog owner". Over and over again it is emphasized that Orchard is not a blog engine but rather a CMS.

A CMS that only supports single user blogging is severely lacking.

I would vote for having this be an essential part of the core, not something that someone can "bolt on" after the fact.

Trying to "bolt on" permissions with a module is sort of like taking a legacy website and telling someone to "bolt on" after the fact handling of dependency injection, buffer overruns and cross-site scripting.

Security needs to be baked in from the start, not addressed after the fact.

Apr 20, 2011 at 3:23 PM
Edited Apr 20, 2011 at 3:34 PM

Pete, the MVM (most voluble modules) right now and IMHO are Advanced Menu and Open Authentication, if you create Advanced Permissions module which will provide for what was discussed your module will make to that list too :). Anyway the point is that for any serious enterprise or community CMS “sophisticated” permissions are critical. For many users it is going be show stopper if that is not easily available, I hope Orchard team is aware. The “MVM list” kind of expresses what are some of the most needed features of CMS system: navigation, authentication and authorization.

Apr 20, 2011 at 4:05 PM
jchannon wrote:

The issue for me as that if I use Orchard as a CMS and I give a paying client access to Orchard, I potentially do not want them to have full access to Orchard's functionality (because they will break everything).  They may also want only certain members of their company to only have editing rights to certain pages of the website.

 

^^^^^^^  my bold above ^^^^^^^^

+1 on this one.

Apr 20, 2011 at 4:12 PM

JonnyBoats - I actually view the core modules more as a "website framework" (something much more generalized than a CMS which far wider applications). In that respect (and I think this is how the developers also see it) the core modules should target the simplest possible scenarios whilst providing extension points so any more complex requirements can be bolted on. The core permissions already provide a lot of flexibility; you can define different Role sets to group permissions, and for each content type you can define different sets of permissions. The only things I think are badly missing from this currently are a) viewing permissions for "private" content scenarios and b) proper user management permissions. Everything else is only required for much more advanced situations. For instance, groups; there you're verging on social network type functionality and it's well out of the remit of a simple CMS / website framework. Per-item permissions; you only start needing this in very complex staff hierarchies where you have a lot of different editors and contributors. And it's perfectly possible to "bolt on" these things after the fact because the right extensibility hooks have already been provided; it's just as secure as the existing edit permissions.

gkumik - I hope you might be right :) It's actually called "Enhanced Permissions" atm. It started from a couple of simpler requirements I had, but as I was simultaneously building the Relations module it became really easy to leverage that and create an EffectiveRoleRelationship. Basically the relationship is between a user and a content item and defines a role that is effected for any permissions tests on that content for that user. It's then pretty easy to define a Group content type and use relationships between the content and the group, then the group and the current user, to apply additional effective roles.

Actually I'd say the Relations module (actually now called Mechanics since it provides Sockets and Connector parts) has the potential to become even more widely used. Looking through the UserVoice requested features, it seemed to me that some 80-90% of things being asked for would suddenly be really quite straightforward once I have this working effectively and optimized. I really want to get something out soon for people to use and to show how it works; the core system is there and it's great, but any kind of UI for editing the many-to-many relationships is necessarily very tricky.

nick - yes, my argument also :)

Apr 20, 2011 at 4:32 PM
randompete wrote:

... For instance, groups; there you're verging on social network type functionality and it's well out of the remit of a simple CMS / website framework.

Generally groups are needed for any enterprise scenario too. I hope Orchard aim is to be the best CMS / framework not just the simple one ;). There is too many great people involved to set for simple...

Apr 20, 2011 at 4:56 PM
gkumik wrote:

Generally groups are needed for any enterprise scenario too. I hope Orchard aim is to be the best CMS / framework not just the simple one ;). There is too many great people involved to set for simple...

Oh yes certainly. But I still don't think Orchard's core features should ever (or will ever) be aimed at enterprise scenarios - but, with its focus on extensibility it's certainly capable of being used in such situations. For an enterprise scenario there are a lot of additional modules you'd need to use, not just groups and permissions. I think Orchard's aim should be to be capable of both simple and enterprise scenarios (and everything in between). To achieve this you have to strip core down to the simplest possible functionality, and leave everything else up to extension points and modules.

Apr 20, 2011 at 5:34 PM

> But I still don't think Orchard's core features should ever (or will ever) be aimed at enterprise scenarios

I believe there is a fallicy here. The flawed premice is that enterprise users require a different set of core functionality than other users.

Those of us who are old timers will remember when we had two grades of Windows, Windows NT was "industrial strength" windows for the enterprise while consumers got Windows 3.1, Windows 98, Windows ME....

I consider it a great milestone when the two versions were unified into a single offering. Please consider what life would be like if Microsoft had decided that features like Access Control Lists, Code Signing, Protection from cross-siyte scripting, dependency injection, buffer overruns etc were only important to enterprise class users?

What would it take to have Orchard at every level adopt the Access Control List (ACL) model as firest implimented in WIndows NT where every object can have an ACL?

 

Apr 20, 2011 at 5:56 PM

I can see the argument; but I don't think your comparisons are entirely fair. The thing is Orchard does allow for Enterprise scenarios by providing extensibility hooks for all those kinds of scenarios. Enterprise features don't need implementing in core, so long as the support is there (which I believe it is).

So yes, core functionality should always provide for both enterprise and standard usage. Yet there are still varying versions of Windows which provide different levels of actual features built on top of that core functionality.

Apr 20, 2011 at 5:59 PM

is it just me or ..........

 

http://www.youtube.com/watch?v=yv-Fk1PwVeU

 

Vs 

 

http://www.youtube.com/watch?v=4Xu-gp0XMmk 

 

I'm off take mein hund spazieren.  

Coordinator
Apr 20, 2011 at 6:35 PM
Edited Apr 20, 2011 at 6:38 PM

ACL do *not* belong in the core or the framework. We implemented the permission system very early and made a very conscious decision to implement only the required core functionality and to exclude everything that could be done as a module. The claim that ACL should not be "bolted on" does not hold. There is simply nothing supporting it given the architecture of Orchard has been *designed* for that sort of concern to be built as a module.

Add to this that most users actually don't need it...

Now on how to do it... If you build this as a part, the storage and management of those ACL is pretty much dealt with. Just check that from a handler and you should be done... What am I missing?

(oh, by the way, implementing with parts takes care of the "at every level" part, due to pretty much everything being content items...)

(in fact there might be a need to touch the Content Manager to add permission checking, TBD)

Apr 20, 2011 at 7:17 PM
Edited Apr 20, 2011 at 8:17 PM
nickHutchinson wrote:

is it just me or ..........

Geez, seriously!!! Pete - you do great work, awesome in fact.  And, we want to hear your suggestions.

But, could you let others express their opinions as well without arguing every dang point?!? E.g. My personal opinion is that Orchards’ already more complicated than it needs to be (Content Item, Content type, Content Part, Content Field, Layout, Template, Shape, Placement, Zone, Widget, Layer…) and likewise, the security scheme is more complicated than it needs to be (at least one other CMSs does it with just “view” and “edit” permissions) whereas Orchard has 7 permissions just for the blog module, 6 for page and list modules, etc…)  So, it's a little odd to keep hearing that the Orchard needs to be so simple.  Everytime I turn around it seems like I need to write another module (or wait for someone else to do it).

Personally I don’t care if you call it enterprise, simple, community or tiddlywinks.  Usually, I also don’t care if it’s in the core or a module (although securities different) – the Orchard team will make that choice. 

Bertrand's comments concern me - I hate the idea of a bolting-on security because I don't know which to trust or what conflicts there will be.  It's like that mess we've got with Windows vs active Directory permissions - you don;t know where to look.  Personally, I can't beleive it doesn't come with the product.   Although having some way to choose which security scheme is active may solve this (my concern is when you have 2 active at the same time as happens with AD and Wordpress+addons).

But clearly there needs to be a way to restrict access. 

Apr 20, 2011 at 8:02 PM

For many users ACL is still “core” functionality which they expect from CMS, doesn’t matter where it is implemented. I guess the point is that Orchard is not CMS but framework to build CMS. Unfortunately looks like there is not much documentation about access control/permission approach and how to extend it to cover non basic scenarios. Maybe some example or doc is all what is needed.

Apr 20, 2011 at 8:54 PM
jsurfage wrote:

But, could you let others express their opinions as well without arguing every dang point?!?

Eh, sorry :P ... the thing is, all the work I'm doing now is based in Orchard, so I'm spending maybe too much time thinking about a lot of these things. And there are security issues that I've already identified will need addressing at some point for requirements that I'm typically going to have (and in fact, already do for a particular website) ... which is why I'm already working on certain solutions, and hence why I have a genuine interest in this discussion. So obviously I'm also interested in debate on the subject because if I'm implementing something I want to do it in a way that would be useful to everyone.

Now, in some of my replies here I was just trying to show that the way I was approaching it was the way I believed was intended by the Orchard team - Bertrand's comment ratifies this. Don't think of it as a separate system - I'm calling it Enhanced Permissions because it takes the existing Permissions and enhances them to give you more control.

On simplicity vs complexity; well, all that underlying complexity is necessary to have a system with enough extension points to allow even more complex requirements to be built on top. In terms of "simplicity"; the core set of features that come with Orchard are very simple, but the framework available to add new features is very rich. The current permissions system is actually just bolted on; it's a module in its own right. That can then be extended to add new permissions. The module I'm building leverages that existing system to add even more flexibility. So in terms of "which to trust" - well it's all the same system, just expanded with more options. So that does make things even more complicated - and I absolutely think people should have the choice whether they need that or not. The fact that each content type has its own set of permissions does end up with a fairly monstrous permissions screen but it also allows for a very fine-grained and flexible permissions model. On the other hand, those DynamicPermissions (which is the name of the implementation in core) could themselves be separated into their own module or feature and maybe that should be done to simplify things a bit for the most basic case.

What the core system doesn't have is basic access control (i.e. a View permission), but as Bertrand has pointed me in the direction of ContentHandlers it might be possible to do something there to hook into the existing roles and permissions system with a new 'View Content' permission. As you point out, there are so many extension points - it's easy to forget about one. To paraphrase, "couldn't see the orchard for the trees" ;P . Actually, I can't believe I just wrote that, and I apologise in advance.

Apr 21, 2011 at 6:21 PM
randompete wrote:
...fairly monstrous permissions screen but it also allows for a very fine-grained and flexible permissions model. ...What the core system doesn't have is basic access control (i.e. a View permission)

Yea, I prefer starting with a KISS approach and then adding the monster when you need it (this is sort of a little monster with a hole in it's head ;-). RBAC would be plenty and ACLs tons of control, although a classification/inheritance system seems needed to make it manageable (are tags enough?).

randompete wrote:
"couldn't see the orchard for the trees" ;P .

Hey, a little humor goes a long way.  Keep up the good work.

Apr 21, 2011 at 11:25 PM
Edited Apr 21, 2011 at 11:26 PM

Bertrand - I've had a look at ContentHandler and also at IContentFilter, and I'm sure I could be missing something but I can't actually see a way at that point to filter a shape from display. The best I can see would be in OnDisplaying to set ShapeDisplayContext.Shape = null or replace the shape with something else ... but I'm worried that could just generate exceptions in other shape events that are expecting a particular Shape to be there, and there's also the chance that events elsewhere could build the shape after I've changed it. Another option might be to set Placement="-" but again other systems could just be changing that back afterwards. What I'm wondering is if perhaps all those context objects could do with a Cancel property so there's a clear and easy way for a handler to prevent something happening (display, publish, unpublish, index, whatever). Or should I just be throwing an exception and raising a notification - that would almost certainly prevent the shape displaying but it doesn't feel very clean. What do you think?

Jsurfage - not 100% sure what you mean about classification/inheritance and tags. Would certainly be possible to have various kinds of inheritance in my model (although performance could start becoming an increasing problem). Could you describe in a bit more detail the kind of system and requirements you're thinking about and how you see it fitting in with the content system?

Coordinator
Apr 21, 2011 at 11:44 PM

That's the thing, from the handler you woudln't filter out, you would redirect. Unless you are filtering out menu item shapes or something. Although removing the shape should not cause any problems in principle. You could even handle OnDisplaying and set the IHtml to an empty string from there. I think there are many possibilities in fact.

Apr 22, 2011 at 12:57 PM

I'm not sure how to redirect from a handler ... is there a particular exception I should throw?

I had a look through the code that runs them and it looks like I could reliably nullify the ChildContent IHtmlString in OnDisplayed.

BUT from a business logic point of view, it will still appear to all intents and purposes that the content has been viewed. For instance Szmyd's view counter (in Advanced menu module) would record it as an actual view. So I'm not sure it's the best way...

May 9, 2011 at 5:12 AM

Orchard so far is amazing, but without view level control by role, the uses of it are greatly limited.  I'm eagerly waiting until this becomes a standard feature.

May 9, 2011 at 1:16 PM

That workitem is now active so hopefully we'll have this soon. It's not actually too hard, mostly just some permissions checks in controllers are needed to vastly improve things.

May 12, 2011 at 3:27 PM

For all still following this discussion:

I've now implemented the enhanced permissions system; for applying additional roles on both individual items and through groups.

It can control Edit/Delete/Publish permissions for individual users over specific content, for groups of users over specific content, and the ability to have supplemental roles for individual users in any given group.

It's basically ACL but what's primarily missing is View permissions. I might end up implementing my own version of RoutePart, in which case I'll build this permission into the actions there and circumvent the missing Orchard permissions. Or, if Orchard gets it implemented at some point then it'll be no problem with normal routing anyway.

The other thing missing is full group hierarchies. That's actually not too hard to add on, but I wanted to make sure the existing systems are stable and efficient (i.e. I'm hoping someone can thoroughly test this first - it's working well enough for my purposes and I have other priorities to move to right now!)

The relevant module is Quanta in the Science Project which I announced in this thread: http://orchard.codeplex.com/discussions/257211

I haven't released this module in the gallery yet but source code is available at the codeplex site. You need to enable the "Effectors" feature for Groups and item roles (generally described as "Effective Roles").

If anyone needs any help or further information please give me a shout!

May 13, 2011 at 4:39 PM

Yes randompete, folks are following this thread.

Our enterprise just began exploring Orchard this week to see if we could use it as a CMS to manage content that different users (or groups of users) could have VIEW access to.  1 week into the evalutation, we are shocked to see that there are no official plans to make content-viewing restrictions a built-in feature.  I agree with the posters who imply that as-is, Orchard aims to be YABE (yet another blog engine) rather than a CMS.

As an admin of an Orchard site, I expect to be able to:
- create a role/group for a client.  eg: "vandelay industries"
- create users in that role.  eg: "george costanza @vandelay industies" and "cosmo @vandelay industries"
- tag content as visible to only specific roles (and/or users)

Is this possible, or do you expect it to come soon?
If this is required as a module, perhaps some guidance for us to go that route?

many thanks!

May 13, 2011 at 5:21 PM
Edited May 13, 2011 at 5:24 PM

Hi sirthomas,

- Orchard WILL have view-permissions at some point in the future. The workitem I previously referred to is now active, I just don't know the exact timescale the team are planning. Even without that, there are a few possible approaches to implementing it modularly, which I will provide in my Quanta module if it doesn't happen soon in core.

- Group/role/content based permissions for edit/delete can be achieved now via the Quanta module.

- The existing Roles system in Orchard is already a permissions grouping system that is very flexible. But Quanta groups add additional layers to that; i.e. you can associate content with the group, so all members of that group will then have specific roles applied to just that content. There are a number of other possible scenarios and more as I develop it. Although I'm just one person and can only do so much, so I'm really hoping to find more people who can collaborate on that and other projects.

- Once Orchard allows basic View permissions I will immediately be able to extend Quanta to apply those for Group and Item scenarios.

- Orchard isn't a blog engine or a CMS; it's more like a modular web application framework. You can completely replace the security system and routing with your own if you like. What is provided in core is just a default set of modules that, yes, give you a quick and easy blog site. But it's capable of much, much more than this. It simply depends on how much you want to put into it.

- In any instance, the fact that Orchard has only been out for a few months and yet already has a 3rd party module capable of such an advanced security model, surely speaks for itself. I'd be interested to know if you're aware of any other CMS that had per-item and group edit permissions at this stage?

May 17, 2011 at 10:55 PM
Edited May 18, 2011 at 4:36 PM
randompete wrote:

Hi sirthomas,

- Orchard WILL have view-permissions at some point in the future. The workitem I previously referred to is now active, I just don't know the exact timescale the team are planning. Even without that, there are a few possible approaches to implementing it modularly, which I will provide in my Quanta module if it doesn't happen soon in core.

- Group/role/content based permissions for edit/delete can be achieved now via the Quanta module.

- The existing Roles system in Orchard is already a permissions grouping system that is very flexible. But Quanta groups add additional layers to that; i.e. you can associate content with the group, so all members of that group will then have specific roles applied to just that content. There are a number of other possible scenarios and more as I develop it. Although I'm just one person and can only do so much, so I'm really hoping to find more people who can collaborate on that and other projects.

- Once Orchard allows basic View permissions I will immediately be able to extend Quanta to apply those for Group and Item scenarios.

- Orchard isn't a blog engine or a CMS; it's more like a modular web application framework. You can completely replace the security system and routing with your own if you like. What is provided in core is just a default set of modules that, yes, give you a quick and easy blog site. But it's capable of much, much more than this. It simply depends on how much you want to put into it.

- In any instance, the fact that Orchard has only been out for a few months and yet already has a 3rd party module capable of such an advanced security model, surely speaks for itself. I'd be interested to know if you're aware of any other CMS that had per-item and group edit permissions at this stage?


Don't find the "Quanta" Module ?

E: ah read the rest of the post..ok