Separate permissions into "Simple Permissions" and "Moderation Permissions"

Hi,
It is by design. I cannot change it. TAC writes values into node_access to each node, and to each user role.

i think you should not give 'update' permission by TAC for those users. Because if they have e.g. 'edit own story' permission (by story.module) then they can edit their own node, without taxonomy_access (even when they have no 'update' permission at all). When you give 'update' permission for a term, than all nodes w/ the given term can be edited by that user role.

Look inside node.module for description (TAC writes values into table 'node_access', that is how it works):
/**
* @defgroup node_access Node access rights
* @{
* The node access system determines who can do what to which nodes.
*
* In determining access rights for a node, node_access() first checks
* whether the user has the "administer nodes" permission. Such users have
* unrestricted access to all nodes. Then the node module's hook_access()
* is called, and a TRUE or FALSE return value will grant or deny access.
* This allows, for example, the blog module to always grant access to the
* blog author, and for the book module to always deny editing access to
* PHP pages.
*
* If node module does not intervene (returns NULL), then the
* node_access table is used to determine access. All node access
* modules are queried using hook_node_grants() to assemble a list of
* "grant IDs" for the user. This list is compared against the table.
* If any row contains the node ID in question (or 0, which stands for "all
* nodes"), one of the grant IDs returned, and a value of TRUE for the
* operation in question, then access is granted. Note that this table is a
* list of grants; any matching row is sufficient to grant access to the
* node.
*
* In node listings, the process above is followed except that
* hook_access() is not called on each node for performance reasons and for
* proper functioning of the pager system. When adding a node listing to your
* module, be sure to use db_rewrite_sql() to add
* the appropriate clauses to your query for access checks.

I noticed this behavior too and I found it strange at first. I am not sure it is a bug. I think it is a misunderstanding caused by the interface.

When the user sees a "Create" permission he *correctly* assumes that it is needed to create content under this category. But when he sees an "Update" permission, he *wrongly* assumes the same thing. You don't need TAC's "Update" permission to edit your own nodes. The "edit own node" permission from the core access control is enough. So, TAC's "Update" permission should be left unchecked or else everyone having that role can edit anyone's posts in this category.

A question is "If it must always be left unchecked, why is it needed?" I think there is a good possibility: Maybe the "Update" and "Delete" permissions can be used for assigning taxonomy based "admins" or "moderators" for some parts of the site, a role which can edit all the posts which belong to some taxonomy terms. But the interface needs cleanup to avoid misunderstandings. The "Update" and "Delete" permissions should be separated from the "List" and "Create" permissions, and put under a "moderators by taxonomy" title or something similar.

My 2c

Yes, i like the idea, since generally Update/Delete permissions should not be checked for users only for content administrators.

My idea on permission page for user role:
Fieldset: Simple permissions (View, List, Create)
- vocab + term list for each vocab (like now)

Fieldset: Moderation permissions (Update, Delete) (collapsed by default)
- vocab + term list for each vocab (like now)

keve,
I like the idea, too!
Is the "version" correct -- does this apply to the 4.6 version? It needs to be modified in 4.7 & HEAD, too.
-Steve

(I modified version and category)

Another idea.

To make the category permission page more simple (it is too complicated and too robust at the moment). I would split already these two types of permissions on the page showing the user roles (/admin/access/category). Beside the name of each user role there would be two links in the table. Header of the table 'simple permissions (View, List, Create)' and 'Moderation permissions (Update, Create)'.

I can also put a eg. checkmark (x) for user roles (in column 'Moderation permission') if that role has ANY moderation permission set.

That is:
Role | Simple Permissions | Moderation permissions
     | (View, List, Create) | (Update, Create)
-----------------------------------------------------------------------------------------
anonymous user | edit | edit
authenticated user | edit | edit
administrator user | edit | edit (x)
etc...

keve,
That idea sounds even better than your first one. I like it!
-Steve

Does anyone think, is this still neccessary?

Since core now has an "edit any" permission for node types, the "update" permission for categories is easier understood.

Perhaps the taxonomy permission could also become "edit any" or "update any".

I think the admin interface improvements introduced in the 5.x-2.x and 6.x branches mostly remove the need for this, so I'm going to close this issue for now.

#364058: Allow configuration of TAC permissions on term/vocab create/edit has further suggestions regarding UI improvements, and #358178: Elaborate relation to core node permissions and #165848: TAC permissions overriden by core? both touch on the somewhat confusing "create" permission and core.