I'm curious how much work/how feasible it would be to extend Drupal to have a more flexible based group permissions system. I understand that you can setup "user roles" and assign a user a role, then define that roles permissions. However, this is very very limited.

I'd like to see a system where multiple groups can be created, each group has it's own permission settings. Then a user can be a member of multiple groups.

A new admin section might be needed, where the site admins assign a user to a group. Or, each group might be able to have it's own administrator, who has authority to add or delete users from their own group.

In addition, the main site admin could juggle users around into/out of various groups as they saw fit.

In addition, I'd like to see the group permissions extended where users could create a group. Then, the users could define what nodes or content or calendar/events, etc... can be accessed by the public at large, or by the user assigned groups.

This would be basically extending drupal more towards the PHProjekt style of user/group permissions. Instead of dwelling in the land of CMS, moving more into the land of CMS/GroupWare based systems. A lot of the basics to Drupal would lend itself well to expanding into GroupWare, just none of the controls exist to manage this.

Any thoughts? Basically, I want to use PHProjekt for my use, but it's too GroupWare oriented, and Drupal is too CMS and not enough GroupWare oriented.

Comments

Anonymous’s picture

I just posted a suggestion:
Combine permissions with categories such that users can have access to certain categories of content.

A true role based permission system has user groups, and permission roles, and users can be member of more than one group of users. This makes for an easy maintenance job for the admin.

If one does it this way, and if the permission roles are not only based on access to a certain module, but also access to categories, then we will have a very flexible system indeed.

Also opt in "subscription" to content for users, based on category would be very interesting.

And now that You mention it - I want to use a groupware system as well. My problem being that Drupal doesn't support table-prefix, which by the way neither does Phprojekt.

Gunnar

Gunnar Langemark@langemark.com’s picture

It was me Only local images are allowed.

BTW: I logged in now - using my Drupal login from my own site - COOL

prowley@yahoo.com’s picture

I am coming to the discussion late, but I got here via search Only local images are allowed.

One thing that seems to be missing from pretty much all CMS I have seen is a real access control mechanism. By "real" I mean a full featured one that will cater for many requirements.

There are basically two things here which tend to get mixed up together, but really should be considered separately: what you are securing and in what ways, and then the mechanism by which it is secured.

To provide for maximum flexibilty (and extensibility) access control needs to be considered at the level of smallest unit of data to be secured. That smallest unit could be as small as a "field" of the form/database e.g. the author perhaps, or even smaller e.g. what values a user is allowed to type in a field. For optimimum flexibility usually one of those two units are used as the base unit, but access contol based on the individual form (node) might be better for a performance compromise. The idea of access control based on entire categories of data will never suit everyone (and doesn't have a hope of coming close). Of course, when considering the types of access control we get the usual suspects, read, add, modify, delete (and very close cousins).

Moving on to how that access control is delivered (the mechanism), for flexibility, as has already been suggested, groups (roles) are a handy way to specifiy access control rules for many users - with the key requirement that users may belong to more than one group. This simplifies administration by allowing the administrator to concern themselves only with what _additional_ permissions that group allows. However, it is not enough to provide only for group (role) based access because there are often exceptions, and requiring a new group to cater for one user is on the heavy side (but may be an acceptable simplification for drupal).

Here is the real departure from the way drupal currently works (as opposed to smallish modifications), there needs to be concept of the _target_ of the access control. It is fine to have category based access control as a starting point which defines _default_ access control rules for new content. However, in order to provide for flexibility each base level unit (as previously discussed) needs to be able to add additional access control rules (which may contradict the default rules, or may tighten them). Then pretty sophisticated schemes for who sees what and who can do what can be concocted.

A word about taxonomy. Definately, taxonomy should have access control ability - this adds another important layer of abstraction for the different data so that the adminstrator can say, enable a certain group of users to see holiday pictures or site specific paid content, but others cannot. You might consider using taxonomy to allow hiearchical layers of default access control rules so I can allow access to holiday pictures, but deny access to holiday pictures on nudes beaches. Now, I am not a fan of how exposed taxonomy is in drupal (but I like the functionality) because it requires admins to understand a fairly abstract concept and how it interacts with the rest of the system. I think taxonomy could be be hidden as a concept and still deliver on its goals and be more useable at the same time - but that's another argument. The point is, access control, like taxonomy, should really be _target_ based so that where admins set their access control rules (as it appears to them, not necessarily under the covers) is on the thing which they are trying to control access. So, for instance, I want to lock down a category of postings to some group, I add the access control rule to the category, if I want to lock a particular post, well, I add the access control rule to that post (in an admin access control field in the form perhaps). Of, course - it will always be necessary (for debugging access control rules mostly) to be able to get a listing of access control rules, possible with refinements like, all access control rules which apply to a certain user.

So, I guess the theme of this post is to introduce the idea that while a page of "permissions" is useful, it won't get you flexible. For that you have to start looking at access control from the other direction, from the perspective of the target data.

Welp, hope I haven't bored you, just some stuff to think about.

Regards

Pete

Dries’s picture

Whether you can assign a user to one or multiple groups should not matter; they differ in terms of administration interface and complexity of the underlying implementation but both approaches are equally powerful. I don't understand why you think a single group approach is "very very limited".

As for fine-grained access control; it is something most of us would like to see happen. In fact, it is quite easy to implement, so I'm confident it will be implemented. For me, the real difficulties arise when you try to figure out how an administrator would like to configure all this ...

Consider just the default access rights or the default behavior, for example. Would you like to configure these for each user group (user roles), for each content type (node type), for each content category (taxonomy), a combination of the above, or ...?

By the way, Drupal CVS already has more fine-grained post permissions compared to Drupal 4.1.0. Here too, we have yet to find a way to let administrators set the default behavior for newly submitted content ("promote to main page", "requires approval", "enable or disable comments", ...).

It is configuration issues/questions like the above that puzzle me, and that stop me from implementing this. Thoughts?

Gunnar Langemark’s picture

The reason for having a permission system that can be applied to categories is that this permits the administrator to set up user groups with access to certain content only.
This enable the site to "cater" to different user groups on one site.
I have had more than one client expecting this from the commercial cms systems that I work with in my daytime job.
You can create a site which will show certain content for admins or for moderators in our world. On a union or organization or a party site (these are my clients) - groups of delegates, groups of parlament members would be able to see the site a little differently from other users.
It is not very often that a whole module should be off limits for a group of users. Not as often as content.

As I see it:
A role based system would benefit from having both user groups AND roles. A role is a set of permissions - which enables permissions to be non-hierarchical.

User groups are groups of users - which should btw be implemented so that users can be part of more than one group.

Also - as part of a flexible system - category based permissions should be followed by a "subscription" setup, in a way such that users may configure the content according to interests:Checkbox all categories of interest, that you have permissions for.

Default: The admin system should be configurable as to whether the permission should be read/write/ or not for each new taxonomy-term. This should be set up on a pr. user group basis.
All new users should default to the standard "users" user-group.
From the box (tarball) the system should be setup to allow write on all new user groups.
Default subscribe status should be "subscribe" - because the option to not subscribe is only interesting if You wish to let users subscribe.

Dries’s picture

I have been thinking about this a little and I think taxonomy-based permissions are the way to go (both for posting and accessing content). If anyone thinks there are shortcomings to this approach, please speak up, and describe your scenario.

The only drawback I can think of is that each piece of content requires to have at least one taxonomy vocabulary (categorization), and that things might get complex or confusing when a post belongs to multiple categories.

adamshand’s picture

I would think that the thing to do would be to have two new defaults.

* If a node doesn't belong to a taxonomy term there should be an admin option which means that it's either completely open or completely closed.

* If a node belongs to multiple terms the admin should choose whether AND/OR applies. Ie. does the most restrictive or least restrictive combination of permissions take effect.

Gunnar Langemark@www.langemark.com’s picture

These two defaults are very good for the admin system flexibility.

The default to the default (the default that the admin meets when setting up the system) should be that content without a category should be completely open. After all - you can hide content completely by not publishing it. Only local images are allowed.
You might also provide a default category - site content or something similar.

The multiple terms question is tricky (as I understand it) - but Your suggestion seems logical. Again the admin should be met by a default at setup time - this default could be the OR option - as this would be the option to choose on a community site where interests are the driving factor. And If there's to be a subscription system added to this then it makes sense.
Example: User X is interested in Open Source Content Management Systems, but not in PHP. Then a news article is posted announcing that a new OS CMS is born: DRUPAL Only local images are allowed.. If the article belongs to both OS CMS and PHP categories, and User X only subscribes to OS CMS - then he should be able to see it.

I agree that there'll be situations where we are in the opposite situation. Where permissions are about hiding content from certain users. Here a taxonomy could be set up and connected with groups of users - so that content can belong to certain groups. I still believe that the OR solution is the way to go here.
Example: Let's assume we have two groups of Moderators - Forum moderators and Blog Moderators. Site Admin has set up two user groups, and two taxonomy categories with the same names. Now he wants to post to both groups of moderators, so he writes a blog and gives it both of the categories. This means that he wants both groups to be able to see the content.

If he wants the AND solutions - we are basicly talking about setting up a hierarchi.

adrian’s picture

But wouldnt it be preferable to have as flexible a system as possible.

I was reminded of high school computer science class yesterday (don't ask .. let's just say it involved someone horribly butchering computer terminology while maintaining to "know it all" (much like some of the teachers i had in that subject)).

Why not implement boolean algebra into the filter string. I am referring to the '.' == 'and' , and '+' == 'or' .. with ofcourse parenthesis ..

so you could say filter=(3.62)+(45.(1+2)) .. (although that is needlessly complex. A simple regex could generate a where string for you. (replace . with or , + with and , and prepend 'tid =' infront of any digits.

You don't lose any functionality from currently .. because filter=1.2.3.4 replaces and=1,2,3,4 .. and filter=1+2+3+4 replaces or=1,2,3,4.

Just a thought.. use it, don't use it.

killes@www.drop.org’s picture

I started working on it. I started with the logic and have not thought about the user interface too much yet. I agree that it is essential to keep that part simple.

Dries’s picture

I just realized there might be a quick and easy way to implement taxonomy-based access control, and thus an easy way to experiment with it and to evaluate its usefulness.

  • First, the taxonomy module uses is permission hook to dynamically export a permission for each term, say "read $term-related content" (eg. "read work-related content", "read school-related content", "read web development-related content" and so on). The permissions can automatically be configured at the "user permissions" page that is part of the "user management" section, and can thus be configured at the level of user roles.
  • Second, for ease of use, the taxonomy module introduces a new helper function called taxonomy_access($terms, $user) which takes an array of taxonomy terms and an optional user object. If no user object is given, the active user is used (if any). The function loops over the terms in the array, and for each term it generates the aforementioned permission string, calls user_access() with the permission string and accumulates the results.

Easy enough. What do you say?

moshe weitzman’s picture

this sounds promising.

- what are the usual permission levels for a term
access: can a user view nodes associated with this term?
associate: can a user associate nodes with this term?
others?

- the taxonomy_form_select() function will need to become access aware as well. if a user cannot associate terms with a given node, he surely should not see the term on the compose page

- i'm, a bit unclear on taxonomy_access(). it seems like an operation should be passed also. for example,

taxonomy_access($arr_nids, "read", "or", 7)

this asks whether uid=7 is allowed to read the nids contained in the $arr_nids array. further, the function should OR together the user's permission for each termr+operation.

- i suggest a dedicated permissions page for terms. would be real clutterring in the main page.

Dries’s picture

The more I think about it, the more I like this approach. Some additional notes:

  • I was talking about "read" access only and omitted "post", "edit" and "delete" permissions for now. As you wrote, it should be feasable to use the same mechanism for different kind of permissions by adding an operation-parameter to the proposed taxonomy_access() function. Good. This ought to be a requirement because we really don't want different access/permission systems to co-exist; we want a single, simple, fast and powerful mechanism.
  • I'm hesistant to create a dedicated permission page for taxonomy based permissions; as a start, I'd prefer to use the existing permission page and evaluate that first.

Last but not least:

  • Rendering the main page, blog page(s), forum page(s) and XML feeds could become a performance killer when done wrong, and thus a potential showstopper for existing Drupal users. Why? Because we might no longer be able to use a simple query to retrieve the ten most recent nodes a user can read. The SQL query below will no longer work:

    SELECT * FROM nodes ORDER BY timestamp DESC LIMIT 10;

    Thus, we need to make sure checking access rights is fast; preferably by doing the right thing at the database level. Suggestions?

killes@www.drop.org’s picture

SELECT * FROM nodes ORDER BY timestamp DESC LIMIT 10;

This obviously wouldn't work anymore. For anonymous users it might be sufficient to add WHERE some_perm LIKE '%0%'.

For authenticated users, who could have multiple permissions, this would not work. I propose to select more nodes than you actally want and then check the permissions on output. This way you might not get the exact number but at least an approximation.

killes@www.drop.org’s picture

I discussed this problem with some friends of mine. They came up with a rather simple solution that would allow us to get only the n most recent allowed nodes.

Dries’s picture

Mind to explain it in this thread?

killes@www.drop.org’s picture

that I hate www-discussions. Only local images are allowed.

Ok, basically I'll have a list of tids that belong to the node and a list of tids that belong to the user. If the intersection between both sets is non-empty, access will be granted.

Those tids get stored in two tables:
table node_access

nid|tid1
nid|tid2
nid|tid3
.
.
.

table user_access

uid|tid7
uid|tid8
uid|tid3
.
.
.

So the intersection would contain at least tid3.

Then you can do:

SELECT n.* FROM node n LEFT JOIN node_access a ON n.nid = a.nid LEFT JOIN user_access u ON u.uid = '$user->uid' WHERE a.tid = u.tid

(and some sorting and limiting...)

moshe weitzman’s picture

isn't node_access the same as our current term_node table (IIRC)?

killes@www.drop.org’s picture

Now you know why I need to ask so many taxo questions. *g*
term_node would contain tids from other vocabularies too but this would not matter.

moshe weitzman’s picture

I may be in need of this capability soon so I want to restart the discussion.

The key roadblock to the 'Dries' plan outlined here is how to quickly select the set of nodes which is visible to the current user. What do people think about maintaining a user_acess table (i prefer to call it user_term) as Gerhard describes? From an earlier post it sounds like Dries prefers mapping roles->terms instead of users->terms. I tend to agree.

I think this approach of maintaining an access table is the only way to achieve necessary performance.

The SQL posted by Gerhard should be enhanced so that we don't hide nodes which have zero terms.

killes@www.drop.org’s picture

Just for an update: the "current" groups module does not use such a table anymore. I found it to be too much hassle to keep it in sync.

Instead, I combined Dries' suggestion about auto-generating access rights with my idea of hierarchical user groups implemented as a taxonomy.

To get the groups a logged in user may view, you have to call groups_get_terms() and it will return a list of tids.

thekenshow’s picture

I've been working on this problem in 4.2.0 for a bit now (prior to discovering this thread :-( trying different approaches - while learning a bit about Drupal! I had tried Gerhard's groups module but it required more patching to related modules than I was prepared to maintain.

I'm using _perm to walk a vocabulary and generate a hierarchy of permissions from it. So the following vocabulary:

Red
- fruit
-- apples
-- pomegranates

Would produce these permissions:

  1. Red
  2. Red fruit
  3. Red fruit apples
  4. Red fruit pomegranates

Somehow, enabling a finer permission (e.g., Red fruit apples) causes the more general ones (e.g., Red fruit, Red) to appear enabled on the user permissions form - however only the selected permission is stored in the permissions table at this point. Submitting the form again then adds these magically selected permissions to the database.

I believe this is related to my question about user_access(), about which I remain confused :-)

My next step was to build and store some form of tid->permission set (array?), for example:

  • 5 -> Red
  • 6 -> Red fruit
  • 10 -> Red fuit apples
  • 12 -> Red fruit pomegranates

So I could easily check any term for access. I was about to ask how to decide whether to set_variable/get_variable or modify/add tables for this sort of storage. At any rate, I'm very interested in this thread...

Cheers
Ken

moshe weitzman’s picture

I think I have a query for the home page which is fast and meets the desired goal of limiting access to nodes based on role+taxonomy mapping.

First, assume a new table called 'term_role'. This table simply maps a term (tid) to a role (rid). An admin page very similar to the 'user permisions' page enables admins to manage this table.

The following query selects all nodes for the home page for a given user.

SELECT n.nid
FROM node n
INNER JOIN users u ON n.uid = u.uid
INNER JOIN term_node tn ON n.nid = tn.nid
INNER JOIN term_role tr ON tn.tid = tr.tid AND u.rid = tr.rid
WHERE n.promote = 1 AND n.status = 1
ORDER BY static DESC, created DESC

This query assumes that nodes with no terms attached are invisible. If such nodes should be viewable by all, then this query has to get a bit more complex.

In order to maintain the same behavior as today, we might have to add entries to term_node table for all new terms and roles. Then an Admin would be responsible for unchecking as needed. Or else some other mechanism needs to be devised for Admins who don't care to use this feature.

moshe weitzman’s picture

I should add that we don't *have* to use a new term_role table. We could use the permission table instead (as Dries suggests above). That query would look like below (note that the following is invalid - no time to tweak it now).

SELECT n.nid
FROM node n
INNER JOIN users u ON n.uid = u.uid
INNER JOIN term_node tn ON n.nid = tn.nid
INNER JOIN term_data td ON tn.tid = td.tid
INNER JOIN permission p ON u.rid = p.rid
WHERE p.perm = CONCAT('read ', td.name) AND n.promote = 1 AND n.status = 1
ORDER BY static DESC, created DESC

This has the advantage of completing half of the _access() check for us.

moshe weitzman’s picture

I have implemented most of what is discused here in a pretty clean and fast way (I think). See Contrib/sandbox/moshe/taxonomy_access for details

joel_guesclin’s picture

I'm looking hard at Open Source CMS systems for one that will allow me to control users' UPDATE access to content, ie: divide the site up into areas such that only a specific group of users is able to update their content, but all users (including anonymous) can SEE the content.

I've followed this thread a bit - but not the technical bits which I don't understand since I don't know Drupal in detail, or PHP - and the more I think about it the more I think you should SEPARATE taxonomy from user access roles.

An example: a "home living" site, with a section on gardening and another on cooking. There is a group of gardening experts who are allowed to update the gardening section, and a group of cooking experts who are able to update the cookery section.

Now, supposing the cookery experts want to update the site with an article about herbs. If you have a taxonomy based permissions system, then you presumably have to assign the "herbs" node EITHER to the cookery section OR to the gardening section, whereas as far as the viewer of the site is concerned - who might be browsing via the taxonomy - he would want "herbs" to point both to gardening and to cookery. Does this make sense?

I would be very interested in knowing what progress is planned/made on this subject, since a good permissions system is critical for my sites.

All the best

Joel

Dries’s picture

And what about post, edit, delete and other content related permissions?

killes@www.drop.org’s picture

Did you look at my sandbox?

Dries’s picture

Yes, but your proposal talks mostly about user groups whereas we are talking about access control. In particular, you suggest to tie user groups to nodes where I come to believe we should tie taxonomy terms to nodes (and roles, not groups, to term-based permissions).

killes@www.drop.org’s picture

My concept is about assigning node based access rights to user groups. Your claim that I'd want to tie groups to nodes is misleading. I want to tie groups (generated by a taxonomy hierarchy) to access rights that are in turn bound to nodes again through taxonomy.

adamrice’s picture

PMJIH, but that's really confusing. As a clueless user, I'd much rather see something like what Dries describes, where roles are assigned to taxonomy terms rather than types.

Creating a distinction between roles and groups seems very abstract. I could understand this if groups take the place of roles entirely (in which case, please keep calling them "roles").

I can see the appeal of managing roles as a hierarchical taxonomy--it fits nicely with the general Drupal framework--but it makes about as much sense to me to be able to clone an existing role and activate/deactivate a few terms as a way to handle term-based permissions. The former is more powerful; the latter is easier to understand. Especially if you get into permissions that don't follow a simple tree-shaped hierarchy.

In short, I'd like flat roles that are assigned something like this:

Role A Role B Role C Role D
Tax 1 x x x
-term 1.1 x x
-term 1.2 x x
Tax 2 x x x
-term 2.1 x x
-term 2.2 x x x

Adam Rice

killes@www.drop.org’s picture

1) In the current groups.module, roles have lost their meaning. The patches remove them from the user admin pages.

2) I can't call groups roles because I think it would be confusing.

3) I am developing groups.module mostly for my own needs. And I am convinced I want a hierarchical groups scheme and not a flat roles scheme.

4) If you'd try out groups.module you'd find that its admin screens don't look too different from what you propose. There are only more of them.

moshe weitzman’s picture

a few mockups illustrating how an admin would actually use this system would be very useful at this point. All who are interested in this topic are encouraged to post a picture like Gerhard's. Pictures of proposed admin pages are also helpful.

p.s. would be nice if the img tag were allowed here.

prowley@yahoo.com’s picture


Whether you can assign a user to one or multiple groups should not matter; they differ in terms of administration interface and complexity of the underlying implementation but both approaches are equally powerful. I don't understand why you think a single group approach is "very very limited".

I am not the original poster but I will suggest a reason why it is limited. It does not scale. If I have 1 thing I want to control access to, lets call it X, there 2 possible access levels - allowed and denied. That's two groups, X-allowed-group, X-denied-group. We only need one group because we are adding permissions (never denying explicitly). Let's add another thing to control access to, lets call it Y, so now we have 2 things to control access to and 4 possible access levels, and we require 3 groups: XY-allowed-group, X-allowed-Y-denied-group, and Y-allowed-X-denied-group. Add another thing to control access to and we get 9 possible combinations which require 8 groups. So you see it quickly becomes hard to cater for all the different access levels that are possible. Imagine the permissions page rendered with a thousand roles.

Now lets look at what happens when we allow users to be in multiple groups. For single groups, 2 things to access requires 3 groups, with multiple groups you need 2 - X-allowed-group Y-allowed-group. Add the third thing to control access to and the single group needs 8 groups, while multiple groups requires only 3 - just add Z-allowed-group. Multiple groups makes for linear progression of administrative burden whereas the single group route makes for anything but linearly progressive burden. In our scenrio above, adding one more thing to control access when using single groups requires many groups to be added for all options which gets worse as the number of things to secure grows, whereas multiple groups always requires only one more.

In short, both approaches may well provide the same functionality but they are definately not equally powerful. Single groups only is an administrative nightmare for anything but the simplest of applications, while multiple groups per user simplifies adminstration and scales with your application.

inteja’s picture

I haven't read the whole thread so forgive me if this is stating the obvious or has been mentioned before, but given Drupal's excellent hierarchical Taxonomy system couldn't group and node level permissions be inherited by default from parent taxonomy terms?

That way, administrators only need to set up root level permissions and then make minor adjustments at different nodes in the tree.

This should make the permissions system highly usable and highly flexible.

Brian.

--
Brian.

killes@www.drop.org’s picture

http://cvs.drupal.org/viewcvs.cgi/contributions/sandbox/killes/group/?ro...

I'm looking for people to work with me together to achieve this.

crisdias’s picture

The experience I have with CMS is that when you have users being able to be members of many groups and "nodes" with permissions to many groups as well you end up with a big mess in user's heads. I personally like the UNIX approach: a piece of content can only be linked to one group; users can be in many different groups. This way you can mix and match as you go.

Gunnar Langemark@www.langemark.com’s picture

If I understand You correctly - You don't like the idea that content can have more than one category associated with it. In effect that is what I am talking about. The taxonomy module allows for that - which is excellent.
The mess will not be in the end users head, but in the administrators head. We must be able to deal with that.
Remember that content does not have a place as such. The content is relevant in more than one respect.

mimi-1’s picture

We need taxonomy/Vocabulary/term permission system. That is the natural way to group people.
Each term can be associated with an administrator/moderator for that term only. Of cource, a user may be administrator for several terms, and a term may have several administrators.

The relationship:
term (m) <--> (m) admin
vocabulary (m) <--> (m) admin
The admin of a vocabulary should be able to admin terms under this vocabulary

Gunnar Langemark@www.langemark.com’s picture

I have looked at PHProjekt and at PHPCollab. I have found the latter to be more interesting for my purpose. Additionally it can take table-prefix, so that It can reside in the same database as Drupal, which unfortunately doesn't support table-prefix.

matt-1’s picture

You might also want to check out the user/group/permissions functionality of XOOPS (a PHPNuke fork with module support and a focus on minimal core functionality). Version 2.0 is on the horizon and should support Smarty templates and turning off register_globals (a big plus in my book). You might want to check it out.

dersmie’s picture

Hi.

I would prefer the permissions handled by the type of content, e.G. something like this:

            |own blog|other blogs|book|story|forum|admin internal forum|...
normal user |rwc     |rc         |rc  |rc   |rwc  |                    |

editor      |rwc     |rc         |rwc |rwc  |rwc  |                    |
admin       |rwc     |rc         |rwc |rwc  |rwcn |rwcn                |

r=read
w=write
c=comment
n= new(create)

You may give basic permissions to every type of content, and specialize it if needed (e.g. admin internal forum).
There should be a possibility to redefine (but only downgrade) permission for every node one creates (e.g. i create a blog entry that dont want anybody to see).
There could be default setting for new inserted modules, so if the module should have these default settings you don

adrian’s picture

I am starting to think that group based access is a bit harsh for my needs.

I require that a certain user not be allowed to post to a certain taxonomy.. and that's it.

I want to bind a user's blog to a certain taxonomy entry. And then only allow that user to write to that taxonomy entry , but the rest of the world to read it.

I want to be able to do quite a few things more than that actually.. but that's the gist of it.

Anonymous’s picture

It's exactly that I want, too.
When Drupal permit that, it is the definitively the most performant CMS...

randall-1’s picture

was anything ever decided from this discussion? user/group permissions or the extended taxonomy system? what is the status, and if it's in a sandbox, whos?

killes@www.drop.org’s picture

There is the groups module in the contrib cvs. The problem is that it is a) buggy b) not fully completed, and c) needs a patch which is seriously out of date. Oh, there is d) the developer (me) has currently not much time.

devin’s picture

Hello everyone. I decided to give drupal a try for a project I am running, and it does everything I need it to, except for group permissions and access. The groups modules appears to have all the functionality I need, but I'm getting patch errors during installation. I've tried using drupal 4.3.0 and 4.3.1, as well as groups 4.3.0 and cvs, with no success. Even after applying the rejected patches manually, the system still gives me odd errors in my browser.

I've read other postings regarding group permissions and the possibility that something similar could be integrated into the core, and I am all for it. Are there plans to do this? In the meantime, however, I was wondering if someone could assist me with getting groups working correctly with a fresh drupal installation. I can post error messages or any other relevant information if needed.

Or, if anyone knows what version of drupal will work correctly with the groups cvs, that would suffice as well. I'd love to use Drupal for my system, but cannot if I do not have permission-based content. Thank you in advance for any responses :)

joebaker’s picture

I know what you mean, devin - it'd be great if this kind of functionality was built into the core.

i've recently tried to place the groups module into a project i'm working on and had similar problems, but been rewarded with much valuable help from the drupal team, especially gerhard killesreiter who's behind the groups module.

the problems i had were resolved by getting the CVS versions of both drupal and the groups module and then working through the patches. it did mean extra work rejigging my existing drupal set-up (themes etc.) to sync with the latest version, but the result was definitely worth it.

i hope that helps you.

tajkovacs’s picture

Can somebody clarify whether or not the groups module works with 4.4.0 yet? There is a groups-4.4.0 file that can be downloaded, but it includes a README-4.4 which states that it is not functional with drupal 4.4.0. If that's the case, then why have a downloadable groups-4.4.0 file? I'm assuming it doesn't work, but figured I'd ask. It's possible that the README file is stale.

Thanks!

killes@www.drop.org’s picture

The module does not work with 4.4. I had to branch the current (broken) version to be able to work on a improved cvs version. In the process I might port back some of the changes. Don't hold your breath,though.

The actual reason for not being too much interested in doing a 4.4 release is this bug report:
http://drupal.org/node/view/6392

This requires even more patches and I certainly am not amused about the removal of a perfectly working feature.

Belfegor’s picture

I think it would be a real shame for Drupal to lose the functionality of the 'groups' module. The future of content on the web, in the case of commerce at least, is in being able to assign different content for subscribers versus nonsubscribers. Correct me if I'm wrong, but this module was the only one that enabled that in Drupal?

Belfy

killes@www.drop.org’s picture

The groups.module is going to be available for Drupal CVS, so there is nothing really lost. I might not have the immediate need to backport changes to Drupal 4.4.

Another approach to content specific permissions is Moshe's taxonomy_access patch. But this is probably even more out of date.

tajkovacs’s picture

I see. Thanks for the quick response. Thanks also for all the fine development you've done on groups.module in the past. I'll keep my fingers crossed that it'll land in the core at some point down the road, but won't be holding my breath.

Alexandr-1’s picture

Hello, Killes and all!
Is there way now to use term/node level permission?
If yes then what version of drupal must be used and what module/patch i need to apply?
Regards, Alexandr

moshe weitzman’s picture

no node access feature has made it into core at this time. seevral modules implement this, but they are pretty experimental still.

Alexandr-1’s picture

Thanks, Weitzman.
Can you tell which modules are provides or tries to provide such functionality?
I dont find any at download page.

robertDouglass’s picture

http://drupal.org/node/view/8917

- Robert Douglass

-----
visit me at www.robshouse.net