There's been a lot of talk about node-level access control on Drupal. I know that there are two threads mentioning access control - one for taxonomy, and one for nodes:
1. Taxonomy access control
2. Node access control
Apparently, Drumm has started design on a Group Management module here: http://cvs.deanspace.org/index.cgi/modules/groupapi/ that I haven't really looked at. Dries, in that thread, believes that proper node-level permissions can not be done in a module and must be done in the core. Before I started anything I decided to write a Requirements Document to ensure that everyone's on the same page, along with a proposal for a UI. I will probably go through the above module with the requirements in mind.
The Requirements document is not that detailed or long. The UI is a little more tedious but provides an idea of how you can manage groups. I have not written a document up on a UI for assigning permissions to nodes themselves, but it would probably be along the lines of a Scroll List with selectable groups, or a text area where you could type in the names of users.
I'm wondering if anyone would mind glancing this over and ensuring that, yes, this is in fact what we want to see in Drupal.
Thank you,
~~~~~
Node-level Access Control Requirements Document
by Irwin Kwan
Last Updated: 2004-01-18
===============================================
Glossary
~~~~~~~~
Element: A set of data.
Create: A user can use the system to generate a new element.
Access: The action of reading, editing, or deleting an element.
User: A registered Drupal user.
Group: A set containing n users where n is part of the natural numbers. Groups are defined by a user. One user may define 0..Inifinity unique groups.
Node: A Drupal node, which is an element.
Access Control: allowing a user to set an element such that only a subset of groups belonging to that system may access the element. A user may only control access to a node that they themselves are permitted to access.
Access Control List: groups that have access to the element.
Node-Level Access Control: access control pertaining to nodes.
===============================================
When a requirement has been fulfilled, please
write your name and the date in which the test
has passed in the small box.
Ex:
[irwin 2004-02-13] Property N: ......
===============================================
[ ] 1: Users always have access to elements that they create.
[ ] 2: Users can manage groups.
[ ] 2.1: User can create/edit a group.
[ ] 2.2: User can assign group a name.
[ ] 2.3: User can assign group a description.
[ ] 2.4: User can add users to an existing group.
[ ] 2.5: User can delete users from an existing group.
[ ] 2.6: User can delete an existing group.
[ ] 3: Users who have access to elements can give access of that element to certain groups only
[ ] 3.1: User can select one or more groups to give access to (creating an access control list).
[ ] 4. Users who are part of groups that are permitted to access an element can view the element.
[ ] 5. Users who are not a part of groups permitted to access an element can not view the element.
[ ] 6. Users who are part of groups that are permitted to access an element, and who are permitted to manage the element type can manage the element.
[ ] 7. Users who are not a part of groups permitted to access an element, and who are permitted to manage the element type can manage the element.
(Rationale: If this was not permitted, then administrators would not be able to manage content.)
[ ] 8. Elements that do not have any groups in its access control list can be viewed by everyone.
[ ] 9. Elements that do not have any groups in its access control list can be managed by those who are permitted to manage the element type.
===============================================
Data Relationships:
User <-- associated with --- n Groups
Group <-- contains -- n Users
User <-- creates -- n Elements.
Element <-- associated with -- 1 Access Control List
Access Control List <-- contains -- n Groups from the SAME user
===============================================
Forum links related to access control:
Taxonomy Access Control: http://drupal.org/node/view/1007
Node Access Control: http://drupal.org/node/view/5073
===============================================
Future Extensions: Deny Access to Groups.
===============================================
Node-level Access Control Interface Design Document
by Irwin Kwan
Last Updated: 2004-01-18
===============================================
~~~
GOAL: Access Group-Management User Interface
ACTION: Click on menu element, beneath "my account", called, "Manage user groups" (or just "manage groups").
RESPONSE: Group-Management Interface Appears. It displays a list of current groups in a Scroll List UI element.
[ Scroll List containing Current Groups]
Button: [Create New Group]
Button: [Edit Group]
~~~
GOAL: Create a new group. (Req. 2.1)
ACTION: Click on button labelled "Create New Group".
RESPONSE: Create Group interface appears. It displays text fields as follows:
Group Name: [____________]
Group Description: [____________________]
Users In Group: [ Checkboxed List ]
Button: [Remove Selected Users]
Add Users To Group: [ Textarea ]
Button: [Add Users]
Button: [Create Group]
Button: [Delete Group]
~~~
GOAL: Add users to the group.
ACTION: Type user name in "Add Users To Group" textarea. Repeat typing of user's name, separated by a separator character (linefeed or comma). Click on button "Add Users".
RESPONSE: System is updated. Reports that the user has been added. User's name is displayed in the "Users In Group" field.
EXCEPTION: If one of the user names does not match with the system, then add only the users that are valid, and report Message to user telling them which users could not be added, and why.
EXCEPTION: If any checkboxes next to "Users in Group" are selected, then ignore them.
~~~
GOAL: Remove users from group.
ACTION: Click on checkboxes next to "Users in Group". Click on button "Remove selected users".
RESPONSE: System is updated. Reports that users have been removed.
EXCEPTION: If any data is typed into the "Add Users" textarea, then keep the content in the textarea.
~~~
Note: for ALL of the above, if the Group Name or Group Description is edited, do NOT save them until "Create Group" is clicked. Keep the contents of the fields in the box.
~~~
GOAL: Edit Group.
ACTION: Select Group from Group Management UI scroll list element. Click on button "Edit Group".
RESPONSE: Edit Group Interface appears. Identical to "Create Group" interface described above.
~~~
GOAL: Delete Group.
ACTION: Select Group from Group Management UI scroll list element. CLick on button "Edit Group".
RESPONSE: Edit Group Interface appears.
ACTION: Click on button "Delete Group".
RESPONSE: Confirmation message appears.
ACTION: Click on button "Yes".
RESPONSE: Group is removed. Return user to Group Management UI.
~~
Comments
Requirements, cont.
===============================================
Data Relationships:
User -- associated with --- n Groups
Group -- contains -- n Users
User -- creates -- n Elements.
Element -- associated with -- 1 Access Control List
Access Control List -- contains -- n Groups from the SAME user
===============================================
Forum links related to access control:
Taxonomy Access Control: http://drupal.org/node/view/1007
Node Access Control: http://drupal.org/node/view/5073
===============================================
Future Extensions: Deny Access to Groups.
===============================================
Node-level Access Control Interface Design Document
by Irwin Kwan
Last Updated: 2004-01-18
===============================================
~~~
GOAL: Access Group-Management User Interface
ACTION: Click on menu element, beneath "my account", called, "Manage user groups" (or just "manage groups").
RESPONSE: Group-Management Interface Appears. It displays a list of current groups in a Scroll List UI element.
[ Scroll List containing Current Groups]
Button: [Create New Group]
Button: [Edit Group]
~~~
GOAL: Create a new group. (Req. 2.1)
ACTION: Click on button labelled "Create New Group".
RESPONSE: Create Group interface appears. It displays text fields as follows:
Group Name: [____________]
Group Description: [____________________]
Users In Group: [ Checkboxed List ]
Button: [Remove Selected Users]
Add Users To Group: [ Textarea ]
Button: [Add Users]
Button: [Create Group]
Button: [Delete Group]
~~~
GOAL: Add users to the group.
ACTION: Type user name in "Add Users To Group" textarea. Repeat typing of user's name, separated by a separator character (linefeed or comma). Click on button "Add Users".
RESPONSE: System is updated. Reports that the user has been added. User's name is displayed in the "Users In Group" field.
EXCEPTION: If one of the user names does not match with the system, then add only the users that are valid, and report Message to user telling them which users could not be added, and why.
EXCEPTION: If any checkboxes next to "Users in Group" are selected, then ignore them.
~~~
GOAL: Remove users from group.
ACTION: Click on checkboxes next to "Users in Group". Click on button "Remove selected users".
RESPONSE: System is updated. Reports that users have been removed.
EXCEPTION: If any data is typed into the "Add Users" textarea, then keep the content in the textarea.
~~~
Note: for ALL of the above, if the Group Name or Group Description is edited, do NOT save them until "Create Group" is clicked. Keep the contents of the fields in the box.
~~~
GOAL: Edit Group.
ACTION: Select Group from Group Management UI scroll list element. Click on button "Edit Group".
RESPONSE: Edit Group Interface appears. Identical to "Create Group" interface described above.
~~~
GOAL: Delete Group.
ACTION: Select Group from Group Management UI scroll list element. CLick on button "Edit Group".
RESPONSE: Edit Group Interface appears.
ACTION: Click on button "Delete Group".
RESPONSE: Confirmation message appears.
ACTION: Click on button "Yes".
RESPONSE: Group is removed. Return user to Group Management UI.
~~
More Requirements Discussion for Permissions/Access
Drupal Access Control Software Requirements Specification
Irwin Kwan
Abstract:
This document defines the Access Control requirements for the Drupal content management system. It explains the different kinds of access control, why users want these features, and exactly what the features must do to fulfill the user requirements.
1 Purpose of the Document
This document details the requirements relating to
permissions control in the Drupal system
(http://drupal.org) . The document is intended to
specify the needs of users for all manners of
permissions, including user roles, taxonomy
permissions, and node-level permissions.
1.1 Why Bother with this Document? Code, already!
The problem currently with Drupal's permissions control is
that it is not very deep. There is no support for
filtering by node types, or for limiting access of
content to certain users. More work is needed to define
what permissions control is, and how to implement it.
Although many people have talked about permissions control,
I get the impression that people don't really know what
it means. This document is designed to allow people to
communicate on the same page. Hopefully, everyone will
be able to understand exactly what permissions control is
to the Drupal system, and what it should do for users.
2 Source of Requirements
The most important source of the requirements comes from users, administrators, and developers communicating on the Drupal boards. http://drupal.org/node/view/5499 is one link that describes a user request for a certain kind of permissions control.
Another source of requirements are the current code available to the Drupal system. Of note are the existing permissions and user roles system, the groups module by Killes (http://drupal.org/project/groups), and the groupapi module by Drumm (http://cvs.deanspace.org/index.cgi/modules/groupapi/).
The final source of requirements is other similar CMS and blogging systems that Drupal shares features with.
3 What is Permissions Control?
Permissions control is the limiting of users to only a certain set of tasks. It incudes assigning users permission to work with various entities on the Drupal system, including managing users, nodes, and modules.
Node-level access control is a subset of permissions control. Users that have a certain access level can access certain nodes on an individual basis.
Module-level access control is also a subset of permissions control. Users that have a certain access level can perform certain actions that are specified by modules.
Taxonomy-level access control is another subset of permissions control. Users that have a certain access level can access nodes that belong to a certain taxonomy.
Drupal defines user roles for Module level access control. Currently, a module defines the actions that can be performed, and the Drupal administrator can assign these actions to different user roles.
4 Requirements Overview
4.1 User Roles
4.2 User Groups
5 User Stories - The Case for Better Permissions Control
5.1 Example 1: User-defined Groups for Node Access
The most common requested level of access is on an individual node basis. Users want to be able to post a node and specifically enable only certain users to see these nodes.
Users most often request this in the context of blogs, where they only want a private group to be able to view their entries.
5.2 Example 2: Restricting user access to different "sections" of the site.
Administrators want to be able to restrict access for users based on taxonomy. For example, a web site may be used for coordination of various role-playing groups. A member from the "Dungeons and Dragons" group does not have permission to post stories to the "Shadowrun" group.
These groups would be defined using the taxonomy system. The Dungeons and Dragons players would have their own "News Stories" that are posted under the "Dungeons and Dragons" taxonomy. These stories would not be visible to Shadowrun players. Similarly, Shadowrun players cannot post stories to or read the Dungeons and Dragons taxonomy.
It should be possible for one user to be a part of both the Dungeons and Dragons and Shadowrun groups.
5.3 Example 3: Adding a new module to a Drupal site.
If an administrator adds a new module to a Drupal site, and wishes to allow only privileged members to use this module, then the administrator should be able to define a group that uses this module and add people to this role at will without an excessive amount of manipulation.
Currently (as of 2004-01-30), the Drupal system only permits users to be a part of only one role. If an administrator adds a module and wants half of his users to be able to access the module, the administrator must compute the set of union of all existing permissions with the module, and then create new groups for each user who has different permissions.
An example is in order:
We have three users: Alice, Bob, and Carol. Alice belongs to the group "Authenticated Users" which can "read news" and "post comments". Bob also belongs to the group "Authenticated Users". Carol belongs to the group "Moderators" and is permitted to "read news", "edit news", and "post comments". We also have an administrator of the system.
Now, the administrator adds a special module called "Filestore". He only wants Alice and Carol to have permission to "download files".
To do this in the one user/role system, the Administrator has to take the following steps:
This problem has the potential to grow at an extremely fast rate, depending on your Drupal site setup. If we allow multiple roles per user, we could simply have added one group called "Downloaders" and added Alice and Carol to this group.
6 PERSONAL BLABBERING ABOUT THIS SYSTEM
We need to decide which takes priority: module permissions, or taxonomy. Right now, there's an undefined dependency going on where we could start at one and go the other way.
What is VERY important is that the taxonomy permissions are inherited. Any top-level taxonomy permission should be traversed down the tree. Going back to the D&D/Shadowrun example, anyone who has permission to "Post Story" in the D&D taxonomy should also be able to post in the D&D » Reviews taxonomy.
Based on this, it may be better to define a UI for a user role that provides:
It is highly probably (FIND EVIDENCE) that there is going to be more fine-grained tuning in modules than there are taxonomies. I think. I need to think about this. Pictures might be beneficial here.
-- Irwin
CVS version of this document
I am looking at the latest (?) version of this document in CVS and have a few questions. Some of the concepts are not clear to me.
Section 4.2.4: Multiple Taxonomy Terms are assigned an "Or" relationship, or an "And" relationship. (Cross Reference) "Or" means, "At least one term in the list must mach the target node to gain access". "And" means, "All terms in the list must match the target node to gain access".
What qualities of a term are matched with a node? Are taxonomy term permissions compared against node-level permissions?
Section 4.2.6: If a user is in multiple roles, then the permissions for the taxonomy term apply exactly.
What does this mean? Is this a restatement of 4.2.9?
Section 4.2.8: For nodes that are part of multiple taxonomies: User in a role can access the node if the role is set up to access "At least one" of the terms in its role, and at least one term in the node is allowed by the role.
The prepositional phrase "in its role" confuses me. Does this sentence imply that a role must have permission to access at least one taxonomy term that the node is a part of?
Section 6.1
What I gather from this is that roles are for module-level permissions in a defined "section" of the site. In contrast, user groups are for taxonomy term-level permissions, which is very nearly the same as node-level permissions.
Varying use of the word "group" in this section and in later sections is confusing.
Section 6.2.2
What are "regular uses?" What does an Administrator do?
Why is User 1 a Role Administrator in every role and not a Moderator? It seems that moderators are higher up in the food chain than administrators, since the former appoints the latter.
Section 6.3
Who performs these operations? A role moderator or a role administrator? Perhaps User 1?
Section 6.4
I thought roles were module-level permissions in a defined taxonomy term. Where is the term defined?
In summary, sections 4 and 6 troubled me the most. Section 7 about node-level permissions made sense.
A few ways permissions might be used.
Here are some ways I could envision using the permission system. Some of them are pretty out there, and are only meant to stretch our imagination. They might help provide a means of evaluating the different solutions that are being discussed.
Leveraging the permissions system, can a module be written to allow for the following uses?
less than 2 weeks old?
Joe Lombardo | Drupal Services: Community-Publishing.net | FamilyTimes Online Journals
Read Access relationships
As far as read access to content goes I drew a diagram of the relationships I'd like to see and put it up at: http://www.malfunct.net/files/diagram.jpg
The idea is that so long as you can find a path from the user to the node that you grant access to the node. Basically this means that one of the "CanAccess" relationships has been met and the node is targeted by the relationship or one of the nodes taxonomies is targeted by that relationship.
As far as write access goes (which I have not yet diagrammed unfortunately) it will have to work differently since you don't yet have a node to work with. My thoughts are that the current role system is fine, its nice to be able to restrict what types of content a person can post. In addition its important to be able to restrict what taxonomies are available for those users to post under. So if you had a site with "private" and "public" taxonomies it would be nice to allow the user to post stories under the public taxonomy but not the private. Additionaly the taxonomies used for security would be heirarchical meaning if public was your top level and someone had write access to public they would get to post to any taxonomy below public, but if they did not have write to public, they could be allowed access to public->travelstories and anything below that but not public->poetry contest or anything below that. It might also be nice to have denies for write access so that you could grant access to public but then put a deny on public->poetry contest so that people would have access to everything under public except for the poetry contest tree.
Groups versus roles.
Why have user groups when we have user roles already? Your document is mainly about groups and hardly talks about nodes or node-level permissions ...
Thanks for initiating this discussion. Good idea to start with a GUI design: it might well be the most challenging part.
User Groups != User Roles
The reason I suggest User Groups is because User Groups and User Roles are not the same thing.
Currently, Users are not allowed to define lists to restrict who and who can not read the content they post. To define who and who can not read their nodes, they have to create a personalized list, which is what I refer to as a User Group.
A user role, as far as I understand with Drupal, is a list of users assigned by the administrators to have access to TYPES of nodes. Because of this, user roles (as they currently exist) can not be used to assign per-node permissions.
Why do we want User Groups? For example, many blogs have the concept of a "Friends List", where you can restrict who it is that views your entries. This Friends List is defined by the user, not by an administrator.
I didn't get that deep in the requirements, so I haven't talked much about the node-level UI or how the implementation would work. Althougn node-level permissions are talked about a lot, everyone has different ideas on what's what and what should be done, so I think we should at least have a good understanding of what everyone wants before we try implementing too much and end up wasting our time.
Thank you,
-- Irwin
Is there an update?
Great clarity in your document. I'm a little frightened when I see Dries comment on roles vs. user groups but I'm sure that your explanation cleared it up.
As someone who is seeing more and more ways to help organizations with Drupal, the permission issue is killing me.
Is there any sense of status on this 'project?' I find it hard to believe this would be an 'external' module given the way it would be intertwined with so much functionality. Is it too absurd to ask if there is any ballpark estimate regarding the length of time necessary to write something that would work well with taxonomy and nodes? GZ
public/private
I hate to chime in with a mere "me to", but some sort of a public/private feature is very important to me too
Complicated permissions
I've had problems with such fine grained access before. The problem is that once you start setting permissions per document, managing them all becomes a problem.
Why not use roles anyway? Things such as a friend list don't necessary require the user to specify everything. Something like this could also be implemented with a pseudo-role "friends" (or even in orkut style, "friends of friends") which include different people per user (dynamically of course). Other than these, I don't really see a reason to split groups from roles.
I think that - if your permis
I think that - if your permissions are connected to the taxonomy system - you could generate a tree which shows which documents can be seen by people connected to which groups/roles on the taxonomy tree.
Only that this tree can get large. Maybe I should revitalise my sitemap.module for this...
--
Drupal services
My Drupal services
What if ...
What if *ONLY SOME* taxonomy terms were referenced from the node table and linked to the roles, permissions using nid and type fields e.g.
That way you could have some taxonomy terms get the functionality of the node system - i.e selected option "node functionality" on node-creation/editing. (See issue:Block titles have to be unique, which they shouldn't for some related comments.)
A generalized access-control system would this way always check the (possible) node id and apply appropriate roles, permissions.
This would be a viable solution to various concerns voiced lately by site creators about access to blog content etc. Having buddy-lists, user-controlled-lists included into this system would be great too. This creates the conflict of which permissions would take precedence, and perhaps a deny/allow system instead of just the allow-system would give the needed flexibility.
Tri-State ACL?
A thing to consider would be using a tri-state ACL. You have can, cannot, and neutral. Just collect all of the ACL that apply to a node (node, tax, permissions), strip out the neturals and you have either "can", "cannot", or "both". In the cases of both, refer to a system-level answer. This is sort of how Apache handles that with the "Order deny, allow" configuration. Another approach is to use the "order" that Drupal already does. Collect the ACL and find the first one that isn't netural. You already have the concept for that.
The advantage of doing that is you can have tax, node, module/permission all at the same time. I know that I will use taxonomy for my permissions but some day I might have a specific node as "private".
If you have associations (i.e. a user is in multiple groups), you just combine all of the ACLs for all of the appropriate groups and process as normally. If you do use groups (which could also be combined with roles depending on your choices), then don't allow user-specific ACL's.
I personally think that user group and user roles are the same thing. They both define a collection of users that has some special behavior or permission (ACL) to perform a task or view a node. I feel that a user should be able to have multiple roles/groups to prevent the subset processing mentioned easier. So, if somone has "D&D Player", "ShadowRun Player", "Balance Admin" (personal plug, its in beta testing) the system will allow them to become a "D&D Admin" without changing much.
Access control by role
Hi,
As I gather the groups module raises a degree of complextity, I am wondering if there is something currently functional that can do this:
rather than defining separate groups, can roles define access to content? How do I restrict access by role? Let's say anonymous users only get the main page or a few pages. authenticate users get more, and trusted users (lets say as board members of an org) get to see most everything -maybe including board-only materials... and site admin is at top...
So, is there a way to achieve this with current modules?
-Michael
Some additional thoughts
I have just come across this post as it appeared next to mine as a recent post since a comment was added at the same time as I posted some thoughts of my own
see this post
You post is about an all inclusive system for node control, and that seems to me to be a laudible aim. One problem I see, and was why I posted the thoughts that I did, was that I think a lot of users may not grasp all the complexities, and need a very simple conceptual model to work with.
Nodes/Taxonomy/Roles
The appeal of Drupal for me is summed up in those three words. I was traumatised when I installed 4.5rc and there was no 'taxonomy' entry in the admin menu - but I digress.
Drupal would be up there with Zope/Plone if it simply treated Roles as Permission Groups. If I could create a 'Term' and then tick a list of 'Roles' granting access, that would satify the need for Node-specific security in my opinion.
Whilst I don't for a second assume this is easy, I believe it is clear in direction.
Drupal is brilliant but...
I was so excited when I finally got Drupal loaded and started to play around with its possibilities. It really is well-featured and flexible. The administration is easy and, apart from the name, taxonomy could be brilliant for organising things. The "Books" function is brilliant and was one of the key features that drew me to Drupal.
BUT I was devastated when I realised there was no "groups" feature.
I run a membership site on e107 which I could never move to Drupal as there are 4 levels of membership with different content for each. I am particularly seeking a framework to manage a community site with private pages for different groups, with forums and content managed by separate people - Drupal can't begin to touch it. And I am working on a project for another community site that needs permissions set for different topics - no go.
It's a real shame. I would love to use Drupal for its elegance. It is a cut above most CMS systems which all seem to be obsessed with exactly the same geeky things. I may try it out for a personal interest site so that I keep in touch, in the hope Drupal will get the proper access control that any community site will need.
Thanks for creating such a good looking system. Please, please give it this core and vital feature.
frustrating, isn't it?
I manage a bunch of blogs. We all need to restrict access to some of our more personal entries. I would _love_ to use drupal.
Sigh.
-samsarra
The finest grain control as the common link
I think that having the linking of taxonomy terms into node-IDs, which could be done for aggregator_item and blocks as well, could be a good solution, if not extracted into a separate content_acl table which could be the base for allowing roles, buddy-lists/user-controlled-lists access to the various content.
Having various permissable and deniable actions like access, create, edit, display (it would get invisible), vote, comment, syndicate, subscribtion, watching, reference (like in bookmarks module etc) would then be easier. Hmm, when I think about it further (the bookmarking set me off here) maybe even an ACL-action system would be needed as various current, future modules would need different actions to control.
Hey, why not have this taxonomy-based access-control-system outlined here expanded even further?
Defining actions and related actions, as well as related *TYPES OF* groups (also taxonomy terms). Then hooks of functions would look up content-id and content_acl definition/data which would list the appropriate actions - a taxonomy term itself - for a group/role - another taxonomy term. Users would be added to groups/roles/lists separately of this. The implementation of the functionality for the specific action for the content would be a function of the format f_acl_<content-type>_<actionable-term>_<group-term>.
Would it be possible to have the function hook related to the ACL-data in a table as well ? Or would this just get into overkill and performance issues ? I was thinking in terms of pruning towards the right function for the selected action on the selected content/node item.
You would then have possibly the most flexible and powerful content-access-control system ever deviced (?). Of course cacheing of the higher-level permissions would be crucial to performance - i.e registerd-users with display-read-comment-vote doable actions for high-level content terms like forum, common blocks etc.
It would have to be a multi-level introduction by a security-access core module, so that not every new Drupal administrator would be exposed to all of this content ACL complexity. I.e having higher level permissions with less flexibility in defining/adding new actions or (especially this:) relating actions, groups, roles.
Does this make any sense ?
edit: I just "went overboard" and outlined a little structure which of course would push the envelope a "little" when it comes to using the Taxonomy-system for security ... but you get the general idea - as well as the sheer power of such a system.
It's not in any way meant as a complete or even working system - just an example of what I was talking about - to capture the essence of such a system.
Any experienced Lisp-gurus out there, or clever EBNF-guys can probably do a lot better than me here. By the way, how does something like EBNF relate in a taxonomy-system ? Can it complement taxonomy ?
groups and policies
[snipped /]
Any progress?
Any progress?
I would vote for such a
I would vote for such a feature too ...
any progress?
any progress?
I'm very disappointed this hasn't appeared to have gone anywhere
I've been searching for days for a way to implement this functionality only to find this 4-year-old post. Has nothing been done in all this time? I see a lot of requests from users looking for ways to implement some aspects of this--I can't believe this hasn't been resolved in all this time.