Advanced options-create delete and update access

I do not plan to implement this. I want TAC Lite to remain as 'lite' as possible. Perhaps you should request user-specific settings be added to TAC.

But since you're requesting this feature, I have to ask: how would you use it? Can you explain to me how the update and delete settings in the TAC module improve upon Drupal's existing access control features?

Remember: access control modules that use the node_access table (i.e. TAC and TAC Lite) affect permissions on a per-node basis. This means you cannot use it to control create permissions, because in the case of create there is no node already. So your best bet for create permissions is to grant some roles the permission required to create nodes - that is, use the standard drupal access control settings. If you control create permission that way, why control update and delete permission differently?

Remember also that TAC Lite controls which taxonomy entries a user can see. So if you give a user permission to create, update and delete stories, but you hide from them the term 'foo', then when creating stories they will not see the term 'foo' in the categories - so they can't create a story about 'foo'. Likewise, they can't update or delete stories about 'foo', because they never see them.

If you can explain to me why this is a useful feature, I may want to implement it. Right now I see it as something that complicates the admin interface while not solving a real problem.

I am of two minds on the need for a create permission. Admittedly, it is not in the node table, but I can still see some value (more at the end of the post).

I do think however there would be use for update/delete (as these are in the node_access table already). Here is a use case.

1. Assume we have a workflow module that uses a vocabulary to mark the states of nodes. Let the vocabulary/workflow contain three states draft <--> under review <--> published
2. Assume we have three roles: anonymous, authenticated, and editor -- only authenticated and editor users can create content.
3. Let the anonymous user have the 'view' permission on published nodes only.
4. Let the authenticated user have view permissions on draft, under review, and published, but no update/delete permissions.
5. Let the editor have view permissions on all three states, plus edit on all three states.
6. A specific use case might be:
   1. User logs in (get's authenticated role)
   2. Creates a story in the draft state.
   3. Uses the workflow system to move the state from draft to under review. The original creator can no longer update this node, as it is now the property of the editor role.
   4. An editor reads, and updates the post. The original author can still see the changes, but can not change the node itself.
   5. After potentially sending the node back to the original author for more changes, the editor promotes the node to published, so that anonymous readers can see it.

While having the 'update' permission helps for most of the work we need to do (specifically preventing contributors for editing their own posts while editors are reviewing them), there is still a problem: contributors can create new posts in the "published" state because there is no "create" permission.

Implementing this is thorny, because it does not map directly to the node_access table. A lot of the bloat in the old TAC has to do with this work. However, I do see it as critical to my needs, so I would like to see it added to TAC Lite.

What qualifications would you put on a patch that implements this?

I can think of two ways (off the top of my head) to implement this:
1. Set a global flag during node creation (hook_nodeapi probably). Read that flag in hook_db_rewrite and limit the returned terms by the creation permission (like it does now for view). (Or could we just ignore the "view" permission in hook_db and only use the create permission? This requires further study of your work).

2. Set the weight of the module to ensure that it is invoked after taxonomy.module. Use hook_form_alter to alter the changes that taxonomy adds to the node form (specifically, removing any terms for which the user does not have create permission).

Of the two, I think I prefer solution #1.

I will have some time to spend on this a week or two. If you think you would commit it, I will put the effort in.

post script: create and update could probably be the same thing from a UI perspective. If a user is assigned the 'edit' permission he/she has the ability to create new nodes of term X and update nodes of term X. Deletion should probably still be separate.

It seems like you're looking for two things. One controls who has permission to edit/create nodes. The other is hiding some taxonomy terms from some forms and pages.

Regarding the hiding taxonomy terms... This sounds like it might be useful on sites that do not use TAC Lite, and it will not be required by all who use TAC Lite. In other words, it should be in its own module. (I wonder if the workflow module helps with that.)

Regarding who has permission to edit... Right now Drupal provides two mechanisms to decide this. The first is hook_access. This is a piece of code that can do all sorts of smart things, for instance checking that the person editing is the same person who created the node. That's why in Drupal's permission table you'll see things like "edit own pages". The second mechanism is the node_access table. This is a one or zero in a database column; it can't be smart. And it only takes effect if hook_access has deferred to it by not returning true or false when it was called. So if you use node_access to grant edit permission on "draft" nodes to all authenticated users, then all users can edit all "draft" nodes regardless of who created the node and which type it is. I don't think this is really what you want.

Regarding permission to create... Only hook_access applies to this.

It's very important to me that the admin pages for TAC Lite remain simple enough for my clients to use. In other words: very simple. And the effects need to be predictable. Once TAC Lite starts to compete with hook_access I'm afraid things will break. For instance, if I install a module that defines a node type and it's hook_access is not well behaved, then the node_access entries will have no effect at all.

In short I still feel TAC Lite is not the place to support what you're looking for. But I do see that what you're looking for makes sense. You could write a module today that does some of the things you suggest with either hook_nodeapi and/or hook_form_alter. But you might also want a new hook which like hook_access can deny access to some operations to some users and like hook_nodeapi gets called even if the module did not define the node (hook_access is called only in the module which defines the node). Such a hook may be what you need, but it requires changes to core drupal.

You mentioned that pieces of the original (and still supported and developed) TAC has code to deal with some of this. Why not use it?

Regarding the hiding taxonomy terms... This sounds like it might be useful on sites that do not use TAC Lite, and it will not be required by all who use TAC Lite. In other words, it should be in its own module. (I wonder if the workflow module helps with that.)

There is a "taxonomy hide" module that prevents taxonomy terms from being displayed on node views. This is not what I meant.

Workflow does not use taxonomy to define states (sadly). I wrote a huge patch against workflow to change from it's own representation of states to using taxonomy terms, but it was met with a lot of skepticism. I'm working on it. I hate to say it, but I smell a fork....

I think am being unclear when I say "hide taxonomy terms." Let me explain by first quoting...

Regarding permission to create... Only hook_access applies to this.

Not true. A user may have permission to create nodes, but that doesn't mean that he/she should have permission to create a node with tag X. This is the kind of permission control the original poster and I are looking for. Example: say we have three terms A, B, and C. User 1 should be able to create nodes with tag A, User 2 should be able to create nodes with term B, etc. This can be accomplished by only presenting 'term A' to user 1 during node creation (effectively hiding terms B and C). Is this more clear?

But you might also want a new hook which like hook_access can deny access to some operations to some users and like hook_nodeapi gets called even if the module did not define the node (hook_access is called only in the module which defines the node). Such a hook may be what you need, but it requires changes to core drupal.

Again, what I want is the hiding of terms during node edit (where editing includes editing new nodes, aka. node creation). I think this makes sense in TAC. However, it could be written in another db_rewrite function, so it could be an additional module. More UI work though....

You mentioned that pieces of the original (and still supported and developed) TAC has code to deal with some of this. Why not use it?

Simple: per user controls in TAC Lite. I am working on a module to provide "sites" through the database, instead of the file system. As each site is effectively a term in a "sites" vocabulary, traditional TAC would require 1+ role for every term, to define local site admins, editors, publishers, etc. With a potential of 300 sites in the first implementation of this module, role and user administration would become a nightmare.

I have changed this from a request to a task and assigned it to me. I will come back in a few weeks with some code and we can go from there. Let's not make hasty decisions about this before we have some code to back it up. Heck, we could always start another module, "TAC Medium" ;-)

Mark,

Here's how I think of the TAC Lite module: It hides terms from some users, and it hides the nodes with those terms. It's simple. It's 'lite'. It's easily understood and easily maintained. At present, it's a mere 363 lines of code.

If I understand what you want, it's to hide some terms from some users, but only in some forms sometimes. This would not be done via grants in the node_access table, which is really what TAC Lite is about. And I stand by my earlier statement that your feature will be of use to a minority of TAC Lite users, and of use to others who don't use TAC Lite. So why not put it in its own module?

Or, if the original TAC supports some of this but lacks only the per-user config, why not add per-user settings to it?

A user may have permission to create nodes, but that doesn't mean that he/she should have permission to create a node with tag X. This is the kind of permission control the original poster and I are looking for. Example: say we have three terms A, B, and C. User 1 should be able to create nodes with tag A, User 2 should be able to create nodes with term B, etc. This can be accomplished by only presenting 'term A' to user 1 during node creation (effectively hiding terms B and C). Is this more clear?

TAC Lite does this. But it hides terms B and C from user 1 always. User 1 will never see those terms or nodes with those terms assigned. This is different from what you described earlier. You described user 1 seeing nodes with the term "published" but hiding that term in node creation forms. You also wanted user 1 to edit nodes, but not edit nodes with the term "published". This special treatment of the term published is not something drupal can do easily.

I suggest you write a module to do the things you need for your site. When that's working it should be obvious how to best share the features with the rest of us.

Closing due to inactivity.