By irwin on

I wrote up a document that talks about Drupal Permissions Control. A lot of people have been requesting it, and I'm beginning some implementation, but I thought that I'd write out exactly what I thought (based on experience, on reading other forum posts, etc.) permissions was. It's been called "access control", "security model", and so forth, but I lumped it under "permissions" in this document.

What I need is someone to help me review it - to get some comments and some feedback to be sure that this is exactly what people want to see. If we do it well, then we won't have to go back and fix it when people complain. I know that we're not trying to IMPRESS anyone, nor do we have any kind of deadline, but I personally think it's nice to know what we're doing before we go do it. So please take a look here and leave a comment as to what you think.

I've highlighted a few "open issues" below, but if anyone finds anything they'd like to comment on or add, please, please do. I really want to make sure that this is what people want to see in a Drupal system.

I'm planning to start implementation in small steps at a time - I'll probably start with introducing multiple user roles, then adding taxonomy permissions, then user groups, then node permissions, or something like that. In any case I'll probably use this document as a guide so I remember what I'm doing.

Thank you!

Full document: Drupal Permissions Control Requirements

Comments

dries’s picture

dries commented

Good document, good insights. I'm glad you get this going. Thanks.

Kjartan and I discussed this a few weeks ago and we believe that taxonomy permissions should be implemented as node permissions. Whenever a node is posted to a specific taxonomy term, its node permissions should be set to the term's default permissions. Node permissions itself should be based on user roles (or user groups), and not on individual users.

Thus, this could be implemented using a new SQL table ...

CREATE TABLE permissions (
  nid int(10) unsigned NOT NULL default '0',
  rid int(10) unsigned NOT NULL default '0',
  perm_read int(1) unsigned NOT NULL default '0',
  perm_write int(1) unsigned NOT NULL default '0',
  KEY nid (nid)
)

... where nid is the node ID, rid the role ID and where perm_read and perm_write are two basic permissions. As such we'd need to add an INNER JOIN to all existing SQL queries that access the node table. There might be other solutions like extending the node table but we haven't explored that in much detail.

irwin’s picture

irwin commented

* Based on user roles: definitely.

It's very insightful to have taxonomy access and node access function identically. It makes sense.

I haven't thought about implementation too much at this stage - I've looked a little at Multiple User Roles and posted a thread here that went unnoticed.

However I have some more insights about the allowable Permissions Set:

From what I see, there are the basic permissions:

Access
Create
Edit
Delete

Moderate (that is, moving in and out of the submissions queue)
Administer (doing funny stuff with a node, such as creating revisions, allowing comments, etc. Administer would probably imply having all above permissions. It would also involve anything that would imply Administration in a module.)

I *think* most regular modules should be able to express their permissions with these terms, or at least, with "renamed versions" of these terms. Let's use Filestore as an example:

"Create Filestore" would be equivalent to "Upload file".
"Access Filestore" would be equivalent to "Download file".
"Search" (from a search module) might be similar to "Access".

For a subscriptions module, you might have:

"Subscribe to this node." --> this is a task that might roughly correspond to "Create subscription".

"Allow others to subscribe to this node." I don't think this is an option with the current subscription module, but if we get this, then I'm not sure if we'll be able to put it anywhere with our simpler model.

The personal conclusion, though - I'd keep it simple. It would be nice to be able to either "alias" or "describe" what the permissions exactly mean on the Permissions page, but I think it would be rare to get a situation outside of the standard "Access/Create/Edit/Delete/Moderate/Administer" (ACEDMA?) tasks.

CVS copy of Drupal Permissions System Requirements

-- Irwin

dries’s picture

dries commented

More comments:

  1. There is no point having a node-level create permission: you can only assign a node its permissions after it has been created.
  2. The difference between the suggested edit, delete and administer permissions is not sufficently clear. It sounds like the administer permission overrules both the edit and delete permission which is bound to confuse people and to complicate the implementation.
  3. It is not entirely clear how we should deal with certain permissions, like for example, the comment permission. If moderate can be a permission on its own, why not let comment be a permission on its own?
irwin’s picture

irwin commented

1. Understood for nodes - but this will be necessary for taxonomy. I will write down the distinction.

2. Should all people who can edit their nodes be allowed to delete? That would make sense. We can then remove the "Delete" permission entirely.

As for Administer - I think I may be falling too much into a mode of "how Drupal currently works". I'm thinking mostly about the "Admin Block" that appears (the one that says, "Promote to Front Page", "Put in Moderation Queue", etc. That stuff is normally controlled by an Administrator.

We may also be able to get away with removing "Administer", and leaving that as "Edit".

3. Understood. The problem with the comment tasks is that they don't fit cleanly into the per-node-permission model.

For example, a group can be allowed to "Create Comment" and "Edit Comment" - which of course implies global effects.

If another user posts a node and he wants it to have it set to "Disallow Comments", then perhaps that should just be lumped under "Edit"?

What this implies is that all users have complete control over their nodes. However, this might also bring us into "Node Form Bloat" if every module we install has a "Disallow _ on this node" option. "Disallow Subscriptions". "Disallow Comments". "Disallow ....".

Do you have any suggestions about how we can deal with these conflicts?

I'm glad we're having this discussion - it helps bring into mind some things I wouldn't have thought of.

-- Irwin

patman’s picture

patman commented

I'm not sure that "Edit" implies "Delete". "Edit", at least in my mind, means "edit the content of this node". For instance, I may create a set of nodes that require copywriting, and assign that activity to a team of writers who have "Edit" permission to those nodes. It would not be appropriate for those writers to be able to delete a node they'd been assigned to work on. It seems to me there's a set of permissions for 'Node Owner', that lies somewhere between Admin and Content Creator.

P

irwin’s picture

irwin commented

I understand the situation you describe, and I think it makes sense. I've left "Edit" and "Delete" as separate permissions.

However, I don't understand your "Node Owner" example, as compared to "Administator" and "Content Creator".

I'm adding some more detail to the document now - I realise that the set of tasks we choose is actually more complex than I envisioned, but it may result in very important benefits for Drupal, including making module development easier and the user interface simpler.

-- Irwin

patman’s picture

patman commented

I'm not entirely certain I understand my example, either... I think "Node Owner" may have been a poor choice of words. Maybe "Topic Owner" or "Term Admin" comes closer to describing what I have in mind. What I am trying to get at is the notion of individuals who have administrative authority over specific nodes, but not site admin rights. Perhaps it looks something like:

  • Bob is the site admin. Bob can do anything
  • Sarah is the Book Review "topic" admin. Sarah can do anything with nodes in that topic (CRUD), including re-assigning those nodes to other terms for which she has admin rights.
  • George is a Book Reviewer. He can edit the content of nodes in that topic, but may not create, delete or reclassify them.

Then again, this may make no sense at all...It's 5:00am, and I'm on my first cup of coffee.

P

irwin’s picture

irwin commented

Well, I think User 1 in Drupal is automatically the site admin, and automatically has full access to everything.

Drupal roles should provide points 2 and 3.

The problem that is on the table is "What permissions should exist?" I'll add your use case to my document and then see what we can do to help provide the functionality.

Is it even possible to do Sarah's job with a Drupal site as it is right now?

-- Irwin

jose reyero’s picture

jose reyero commented

I think this is ok just for node-roles based permissions, but I propose a more flexible one, so we can have more types of permissions and all of them could be managed in one place. These could be the fields:

- type = role|group|user|whatever....
- object = node|nodetype|taxonomy_vocabulary|taxonomy_term
- id =will be uid, nid, tid, vid, depending on the object or a given value , 0 or NULL, for all the nodes of the same type)
- access = read|write|admin|.....
- allow = allow|deny, or 0|1

Just think about the flexibility and extensibility of this kind of schema. We could add a permissions.module replacement to switch from role-based permissions to group-based. I'm not very happy with having only role-based permissions...

Yes, It's more complex, but we don't need to implement all the complexity in the first try. So we can start having only node-role-allow permissions, but the schema will be flexible enough to support more complex ones in the future without patching the db schema.

https://reyero.net

njivy’s picture

njivy commented

Before stumbling across Drupal, I spent some time playing with Xaraya. The flexible permissions you describe remind me of Xaraya's permissions. But here's the rub. To implement simple access controls in Xaraya took me many hours of fiddling.

Flexibility is nice, but it must be usable. This, I think, is the reason Dries, irwin, and others are working to reduce the permissions to a reasonable and intuitive set.

jose reyero’s picture

jose reyero commented

I agree 100% with your 'Flexibility is nice but it must be usable'.
But notice we are talking here about low level implementation, database tables... If we make it flexible enough, then we can have a 'simple permissions' module and a 'advanced permissions' one and whatever you want.
My idea is setting up a flexible enough base system, and then let the UI to specific modules. We don't have to implement al the capabilities in the first try, but we will be able to extend it in the future without too many changes to the database.

https://reyero.net

moonfire’s picture

moonfire commented

If a node takes on the permissions when it is created/updated as a default. What happens when someone changes a role's permissions? If I want to give a role a new (or remove it) permission, does that mean I would have to go through EVERY node and fix it?

dries’s picture

dries commented

A problem that hasn't been addressed yet in much detail (AFAIK) is whether node-level permissions should be extendable. That is, should a module be able to register new node-level permissions or do we opt for a pre-defined set of permissions (i.e. read, edit, delete)? If the permissions should be extendable, how can this be implemented? After all, such requirement would have significant implications on the underlying design.

Take the comment module for example. This module might want to introduce a new node-level permission called administer comments. Similarly, a workflow module like the queue module might want to introduce a moderate permission, the image module might want to add a new permission to allow/dissallow certain image manipulations, and so on. Of course, one could argue whether this kind of granularity buys us anything but complexity. If the user has edit-permission to a node, why not let him edit the node's comments and images as well?

I prefer a pre-defined set of permissions as I want to keep this as simple as possible, yet I realize this might not be sufficent in all scenario's. Maybe we should collect some use cases that touch upon this specific problem?

irwin’s picture

irwin commented

I honestly do not envision that we need much more than a relatively standard set. It won't be limited to Create Edit Delete... we may also have Moderate (this appears to be most relevant for submission queue). Drupal already has a "search" (which seems a little extraneous, personally), and there's confusion between "Administer", "Manage"; "Post" and "Create" that can be eliminated if we define a standard permissions set.

To collect use cases, we need to talk to more users who play the Administrator Role. We can either ask them to come and comment, or we can go out and look for them. A lot of us (Drupal developers and site browsers) are administrators, so hopefully we can get a few comments here and get some perspectives. I'll probably look at other systems as well, or browse the forum topics that exist.

I'll add these points to the document, Dries. I'll get a CVS copy checked in and linked some time tomorrow.

-- Irwin

Bèr Kessels’s picture

Bèr Kessels commented

just my two cents.

I thought it might be good to not re-invent the wheel, so i looked at a very often used permission system: CHMOD.

For those unknown with this system: http://campuscgi.princeton.edu/man?chmod

The big difference lies in the fact that we dont want to execute anything. Or at least: we don't want execute permissions. I would not see why, anyway. And of course we would be reading 'nodes' instead of files, and taxonomy instead of directory.

After that is said: we /do/ want difference in administrate and edit.

imo the diff. between administrate and edit lies in the fact that 'administrating' a node means placing it somewhere in the site (frontpage, bookplace, moderation queue etc) and edit means just editing the contents.

So if we would replace the chmod mode /execute/ with /adminster/ I think we can take over this approach.

One more note: Each group (role) has a weight or a place in a tree. This is the group appraoch that was already described in this thread.

Ber
Mediarevolution.org :: het platform voor online muziek

irwin’s picture

irwin commented

patman's example with Bob, Sarah, and George is a good example on why a simple unix-style chmod probably won't work. chmod provides basically 3 permissions - read, write, execute. It ignores create, edit, delete, create node, reassign node, etc.

However, if you're thinking about Drupal = Unix filesystem, the chmod might be a useful analogy (but not an actual design).

I mean, all nodes can be easily considered as "files". Taxonomies can be considered as "directories".

Drupal gets complex not because of its taxonomy/node structure, though. It gets complex because of modules that add little features to nodes - subscription, commenting, avatars, HTML textareas, etc. How would we ever get User Role Administrators to properly enable and disable all of these features?

This is a rather complex problem - I hope we can keep this discussion up and find some solutions - if not perfect ones, then good ones that will allow us to add the functionality to Drupal without locking ourselves out of future advancements.

-- Irwin

irwin’s picture

irwin commented

Something else here just clicked - your idea of chmod covers the idea of ownership as well as permissions. This adds an extra level of complexity.

Would it be useful to specify Owner Permissions, Group Permissions, and World (anonymous user) permissions? One issue with this is that Drupal would not necessarily need to be limited to one group, like the Unix filesystem is. However, the ownership issue is important. For example, most users are permitted to edit their own nodes, in general cases. However, users should NOT be permitted to edit nodes that they do not own.

What I need to do is to put together a list of the different options we have so far and help crystalize them. I might make up some mock GUI screenshots and write a kind of "User's Guide" in an attempt to explain this as if an end user was working with the system.

-- Irwin

patman@drupal.org’s picture

patman@drupal.org commented

It occurs to me that Moderate == Admin, but scoped to specific topics. One could also argue for keeping the CRUD model, but applying it to nodes as well as to topics. Therefore, Create Node enables one to submit a node for publication (if the topic is moderated) or to publish a new node to the site (in the case of unmoderated topics). Edit Topic (Term?) could provide the moderation ability you discuss above.

P

irwin’s picture

irwin commented

What's CRUD? It's something like Create, R.., Update, Delete?

Do you think you could write a more extensive example of what you mean? I'm not entirely understanding it at this moment. Maybe you can fill it in a little more for me?

-- Irwin

bertboerland’s picture

bertboerland commented

Acronym finder: crud

So you on the right track, you just needed the "read" bit

--
groets

bertb

--
groets
bert boerland

qgil’s picture

qgil commented

> To collect use cases, we need to talk to more users who play the Administrator Role.

Just my two cents with a specific problem we have now that we are moving from Geeklog+TWiki (tools with a good groups&permissions management) to Drupal.

We are a cooperative and we have these roles: anonymous, registered, volunteer, collaborator, partners and superadmins.

Setting permissions at a module level is not enough. For instance, we want to offer open access to the books and files, although we want some pages and files accessible only to partners (i.e. confidential information about clients or invoices pending to be paid).

Although setting permissions at a node level would be possibly the most accurate solution, maybe most of the problems could be solved by setting access permissions using taxonomy.

As an example, for us a specific solution would be:

- Only partners can upload/manage files and manage books and by default all users can access them (this is already possible).

- Administrator creates a new optional vocabulary "Restricted to" listing as terms the existing roles. Therefore when a partner uploads a new file or publishes a book page can optionally restrict the access to one or more roles, or just leave it to make it accessible to everybody.

Ther would be still some problems related on permissions on editing and so on, but the main problems are related to showing/hyding specific content to determinate roles.

I recommend you to have a look to Geeklog's system of permissions. I'm not a programmer and I don't know how compatible is with Drupal's architecture, but I find permissions management is one of the best Geeklog's features.

Larry Cannell’s picture

Larry Cannell commented

So this is looking pretty good. I have some input though as role-management is something I have been looking at (in other capacities) for some time.

When you look to roles or groups consider using them in other contexts. Basically, a group is a list of users (ok, maybe a group can include other groups, but in the end you have a list of users). Security is one thing that can use this list. However, there are other applications that need lists of users: email distribution lists, instant messaging buddy lists, and probably others. Wouldn't it be cool if the group that lists the members of my team is the basis for providing me access to a drupal node, is the distribution list I can send email to, and is a server-side buddy list I use with my instant messaging client?

Also, the source of this list can come from elsewhere. In the same sense that user logins can come from say an LDAP directory, so can groups. LDAP is one potential external source for groups. So consider external hooks for this information.

To summarize, consider the following for groups:
- Use for other capabilities besides security, like email
- Leave open the option of hooking into external sources

--
Larry Cannell
larry@cannell.org

irwin’s picture

irwin commented

I'm brainstorming a little and I'm starting to think up some better models than what I have in my document.

The important actors in a Drupal system, regarding the requirements are:

Users - those who view nodes and create content.
Administrator - The site administrator (User 1)
Moderator - people who manage user roles

Terms - taxonomy terms; they are basically "sections" of a site.
Node - site content

One model I have right now is the following - this is for taxonomy permissions, and not individual node permissions.

A Taxonomy term has:

- a list of "moderators" who manage the content assigned to the term.
- a list of "group members" who are users associated with the term. In theory, the moderators would be the ones who assign group members to this term. The site's superuser would assign administrators to the term.

When one wants to assign Task Permissions to a term (and therefore all nodes beneath the term), there are three steps (in this model) that you must follow:

1) Select the actor who would be executing the action.
2) Select the action the actor performs.
3) Select the object type the actor performs the action on (a target).
4) Ownership.

Actors would include:

Node Owner
Group/Term Member
Group/Term Moderator
Anonymous User

Actions would include:

View
Create
Edit
Delete
Administer

Targets are:

Node
Comment
other module types

Ownership is:
Your object
Other people's objects

To assign a permission, you present a list of all combinations of permissions (not exactly like that...) and get the Administrators to choose which ones are allowed.

So, for example, the administrator can assign a permission that is like:

OWNER can CREATE a NODE that they OWN under this term.
ADMINISTRATOR can EDIT a NODE that they DO NOT OWN under this term.
ANONYMOUS can VIEW a COMMENT that they DO NOT OWN under this term.

While this model appears to be pretty complete in capturing all possible permissions, it also suffers from the fact that you'll get a ridiculous number of combinations, and many that don't make sense, such as:

ADMINISTRATOR can CREATE a NODE that they DO NOT OWN under this term.

One might ask exactly how you create a node you don't own, for example.

Now, the "object type" can be eliminated based on the existing taxonomy system - it limits by type, so you can automatically remove one field and that will dramatically shrink the set size.

A limitation of this model is that one can not easily assign permissions such as "comments not allowed". You would have to extend the model to include a "subject" and a "target" for the verb so you could compose a sentence like, "GROUP MEMBER (person) can NOT CREATE (action) a COMMENT (subject) on a NODE (target) that THEY OWN (ownership)."

There's fancy Grammar terms for all of these, of course. That ALSO brings another problem dealing with localization and translation that we must consider.

~~

One can use a set of "default permissions" for this kind of system and assign the permissable set to the entire site - applicable to the "null" taxonomy term and all terms, unless explicitly overwritten.

~~

So basically, ONE group is associated PER TERM, and there are administrators PER GROUP.

* Alternately - a site administrator could, instead of assigning groups to a term, could create a user role with a moderator, and then assign the group to multiple terms, which might be more flexible than the above system. The moderator would be able to control the properties of that user role, IN ADDITION to the site administrator.

I'm talking about many concepts here at the same time - so let me summarize quickly.

I) Every user role has a set of "moderators" who control:
1. Permissions in the role
2. Users who belong in the role
II) Assigning Permissions. There are four elements that need to be assigned in every permission:
1. The person performing the action (Moderator)
2. The action (Create, View, Edit, etc.)
3. The target (node, comment, etc.)
4. The ownership (your own, other's).

-- Irwin

yktdan’s picture

yktdan commented

I have a lot of problem understanding why one wants anything more complicated that read and write permissions. If one can edit (write) anything it is equivalent to delete because you can edit the content to be nothing. The only issues are structural issue about tests for existence. Similarly create can largely be bypassed by editing the content of something that exists to what you might want to create (aside from space consumption issues which are better handled with quotas because it is the space taken, not the number of nodes that is important).

Walt Daniels

Brian@brianpuccio.net’s picture

Brian@brianpuccio.net commented

Why not borrow linux file system permissions or a variant of them?

gatezone’s picture

gatezone commented

I't is critical that there are basic read/view/access or noview/access permissions at each level of the system assignable to groups (NOT ROLES) of users. For some people who are not familiar with system access permissions on other systems it is easy to get mixed up with Roles and Group types of permissions.

Right now I can create roles that have access to specific *features* and *actions* on the system, but I can't create a 'role' that only has access to certain Vocabulary, Terms, or Nodes regardless of their ability to 'execute' or write within those same Vacabulary, Terms, or Nodes. Furthermore if I want one individual to have access to one node only it isn't possible with an unmodified Drupal system. There are cases where you don't really want to create a group with one individual in it, but that's one way it is done in some systems. Usually there are individual 'rights/permissions' as well as group. See phpbb and other systems. Just don't model anything on the postnuke permission system please ;-).

If I'm incorrect please help me understand better, but a "role" is a very different animal than a group.

What is the status of group/individual permissions module or inclusion in the core? Is it within the 4.x line of development? This feature will take Drupal to a new level within organizations. -GZ

Gunnar Langemark@www.langemark.com’s picture

Gunnar Langemark@www.langemark.com commented

A role is a set of permissions. That is you group permissions and say: anyone with this role can see/write/execute etc this and that.

A group is a group of people. That is to say: These people have something in common.

If you have both you can put people in groups and apply roles to these people. Lets say you created a group called "Volunteers".
Now you have a role called "Contributor" and a role called "Forum Moderator".
First you say: "ok my volunteers need to be able to contribute" - so you give them permission to contribute. After a while you want them to be forum moderators too - so you just add that role to the group too. That is ONE action.

Now Taxonomy permissions would be different from this, Individual permissions and Node permissions would be different from this.

Taxonomy permissions would enable us to set up a taxonomy - where terms or whole taxonomies had permissions. This could actually enable node permissions because it would make it possible to attach a certain taxonomy term to a given node, and thereby permissions.

Individual permissions could be set up by setting up a role for a single individual - which is not elegant.

The real challenge is to have a default setup - or a number of possible preconfigured setups - so that a very flexible system does not make it cumbersome to work with Drupal as an administrator.

Perhaps it calls for a change of attitude. Drupal is now so much more advanced than what it was in version 4.0, that there need to be focus on preconfigured setups of some kind.

Best
Gunnar

Dropping in from Langemarks Cafe.

Larry Cannell’s picture

Larry Cannell commented

I don't want to get into an argument about semantics. I know the term "role" is already being used in Drupal and so that will influence what people think a role is.

However, if you look at roles the way you do in your personal or professional life you may see there is little difference between a role and a group. I also think that if Drupal has both roles and groups it will confuse people and whichever one has the most functionality will be used. The other may be dropped from use entirely.

IMHO, roles and groups represent the same thing: a list of people. The only difference is the way we describe and use this list.

A role describes people with particular attributes; either inherited, purchased, earned, etc. For example, I take on several roles in my life: a father, husband, brother, son, boss, employee, book club member, etc. Each role has different responsibilities, benefits, obligations, etc.

A group is another way of describing a set of people. I belong to a Linux user group so I am a member of a lug (a role). A CIO (a role) is a member of Forrester's CIO Group.

The only caution I have is to reduce the confusion between a role and a group. We will eventually (if we haven't already) talked about assigning a role to a group (or vice versa) which is really not too different from allowing groups to contain other groups.

Also, groups aren't only applicable to security (although it is THE major use, no doubt). Think of other uses for groups like email lists and IM buddy lists.

Group definitions should be centrally accessible just like member definitions. So, think about accessing LDAP groups to enable a consistent definition of a group within a company's directory.

A team is a good example to illustrate the need for groups. As a team we may use several tools to assist us in collaborating: email lists, IM buddy lists, Drupal for sharing documents, etc. Whenever there is a change in team membership (someone leaves or someone new joins the team) how many places will the team admin have to go to update the tools? Wouldn't it be cool to change the team membership in one place and have all the tools respect that? In fact, I would argue that it is much safer (and auditable) to do so (in addition to being convenient for all team members).

btw: If I belong to a team is that a role or a group?

--
Larry Cannell
larry@cannell.org

dealingwith’s picture

dealingwith commented

I agree that roles and groups should not be distinguished by default.

I set up roles thinking to assign rights to DO things _and_ rights to ACCESS things. Surprisingly, I find that the out-the-box Drupal implementation only allows roles to _do_ things and has no _access_ control (for me it doesn't matter if it is on a taxonomy level or a node level, although I also agree that nodes should simply inherit taxonomy level rights and it is therefore one issue {re this thread}). I would think access control would be easier to implement.

As far as the UI, it doesn't matter to me if it is on a role permissions page or the taxonomy page, or even if I have to specify access permissions to every taxonomy term seperately--my implementation doesn't have to scale that much ATM.

The groups module seemed to include access controls, but again seperate from roles, and besides it is apparently still broken in 4.4, which I just upgraded to so that taxonomy_menu would work! (At first it {"groups"} seemed to be included by default in 4.4, but still broken. I Am Confused About This, Obviously.)

Since my implementation is of such a small scale, I will probably just create subdirs with code that queries Drupal's role tables. This is obviously a sub-par solution...but couldn't the same concept be applied to the core Drupal content control pieces just as easily? This would quickly allow for SOME access control while the various parties endlessly discussing how this should come about long-term continue...um...discussing...

--daniel

Luke Diamand’s picture

Luke Diamand commented

So - is it possible to configure drupal so that members can see all documents, while non-members can see only some documents, with 4.4.1 or 4.4.2?

Thanks

killes@www.drop.org’s picture

killes@www.drop.org commented

No.

--
Drupal services
My Drupal services

Luke Diamand’s picture

Luke Diamand commented

That's a shame. Drupal seems excellent in all other respects :-(

dealingwith’s picture

dealingwith commented

Can anyone involved more intimately with this give us an update?

--daniel

irwin’s picture

irwin commented

I wrote the document about one year ago, but since that time, things happened and I have been unable to pick up from where I left off. In early March I almost had a design completed, but then my computer crashed and I lost everything including the document and my initial untested design.

Depending on how much time I have, I might pick up this issue again and study it. However, I have to check out the changes in 4.6.0 before I can proceed any further. Chances are someone's managed to beat me to the punch and implemented permissions already. I have to dig out the sandboxes and contrib modules to find it (if anyone knows offhand where they are point me to them).

-- Irwin

jlinares’s picture

jlinares commented

I'd like to have a complete, web based and flexible permission system in Drupal. This is the more complete thread that I've found about this topic. Does anyone know the state of the art of all these stuff? Has any complete solution already been implemented?.

jared12’s picture

jared12 commented

Ha ha ha. Click the link and I get a 403 error:

You don't have permission to access /~arcana/htmlsrc/ on this server.

Very funny. Guess this is ancient though.