Just an idea regarding the current issues with this module... I was thinking it might be more appropriate to implement a more unix-like permissions module to taxonomy terms.

Under this new system, each term would have read and write permissions for user, group (role), and all.

With read permissions, a user is able to access content posted by either them, members belonging to their role(s), or everyone on the site.

With write permissions, a user is able to create/edit content posted by either them, members belonging to their role(s), or everyone on the site.

Under this system, we would have the ability to give a user permission to create a node (like a forum topic) and assign it a taxonomy term, while preventing them from editing any user's post assigned the same term. (This is currently my biggest beef with this module ;-)

Another benefit is the ability to easily create sub-moderators or group-moderators, giving them access to moderate a certain taxonomy.

A final benefit I see with this system is the level of similarity to existing unix permissions, which many of us are familiar with.

Any thoughts?

Cheers,

Kieran

Comments

Kieran Huggins’s picture

Kieran Huggins commented

set the wrong status :-)

pyromanfo’s picture

pyromanfo commented

This is too much of an architectural change for us to implement.

For starters, allowing people to post content but not be able to update other's content is coming by adding a seperate "create" permission. That will be easy enough, and it doesn't break ranks with the existing node_access in core.

Also, you can already create sub-moderators, by giving them update and delete permissions.

If anyone was to implement this idea, it'd have to be the core guys first. It'd require changes to the node_access hooks and almost every module that's already implemented node_access checks. So you'll really want to talk to them.

My take is that it's just too complicated when what we have now will do pretty much everything the new system would, it's simpler and it's already implemented (minus the create permissions).

Kieran Huggins’s picture

Kieran Huggins commented

Good points. I understand where you're coming from, and I've proposed the architectural change to the core guys.

The "create" function would work in my case, but what about instead adding a "user scope" of : user | role | all.. Might be more flexible. By default it could assume "all" to keep compatibility with existing modules / core.

Alo, this would break less in the upgrade to new user perms inthe future...

Ideas?

Kieran Huggins’s picture

Kieran Huggins commented

someone anonymous in the "node access" issues forum has suggested using the existing "realm" column of the node_access table for user scope... is this an appropriate use of this column?

Kieran Huggins’s picture

Kieran Huggins commented

"someone anonymous" turned out to be JonBob, which makes me believe he knows what he's talking about...

Is this the kind of change you guys are willing to look at at this point, or does this justify a new module altogether? I don't want to promote unneccesary module duplication / feature skew, but It seems that this feature is in high enough demand to warrant implementation in some form.

cheers, kieran

pyromanfo’s picture

pyromanfo commented

That could work, and it may not be a bad idea, but I just don't have time to do it right now.

If you or anybody else wants to make a patch for it, I'd definitely check it out and help where I can.

andrew404’s picture

andrew404 commented

This would help me out with menus.....

Currently using Taxonomy_menu....

If I could set the roles that have access permissions to particular roles, the menu could be generated with the allowable terms(sections, categories) for a particular user.

Am I on the right track as to what you guys are speaking about?

keve’s picture

keve commented
Priority: Normal » Minor
Status: Active » Closed (fixed)
keve’s picture

keve commented
Title: Proposed revision of access control » Proposed revision of access control (more UNIX-like permissions)