Hi,
I face a strange behaviour :
When I give a role, the right to update node, I'm able to edit the node and save it, but the problem is that doing this will lost the taxonomy classification.

This is because taxonomy_node_form with patch require a "create" access.
So I think this is a little problem because you can't edit correctly node with only "update" access, you need both "update" and "create".

CommentFileSizeAuthor
#5 taxonomy_19.patch3.13 KBjohnalbin
#2 taxonomy_18.patch1.89 KBjohnalbin

Comments

johnalbin’s picture

Component: User interface » Code
Priority: Minor » Critical

I'd like to reiterate tostinni's comment.

If a user edits a node assigned with a category for which that user only has "view" and "update" permission, the original category is not shown in the edit category pull-down. The only categories shown are those that the user has "create" permission for.

I'm trying to setup a public website that has mostly private content and I've set up a taxonomy like this:

  • Content Viewable By
    • Private
    • Public

I've given Authenticated Users the ability to view, update, delete, and create Private content and the ability to view and update Public content. I only want the admin to create Public content; the admin can then assign that node to a user to maintain.

Unfortunately, the user cannot maintain that content without the category switching from "Public" to "Private".

This is a show stopper for this kind of website. Because the users (who are capable of editing content) are not knowledgeable enough to be admins and should NOT be given the ability to create public content.

johnalbin’s picture

StatusFileSize
new1.89 KB

I believe I've fixed this issue.

The problem was that taxonomy_node_form causes taxonomy_access to check 'create' access when a node is being updated.

taxonomy_node_form can tell the node is being edited by checking $node->nid, but that info is not passed to taxonomy_form and then on to _taxonomy_term_select. Ultimately, it is _taxonomy_term_select that checks the 'update' privilige and generates the items in the taxonomy pull-down.

The attached patch works with the 4.6 taxonomy.module that has already been patched with 4.6 taxonomy_access's taxonomy.patch.

I hope the maintainers will find this patch useful.

tostinni’s picture

Status: Active » Needs review

Thanks for the patch, I didn't took the time to check it ;)
Change the status.

johnalbin’s picture

Unfortunately, my patch is only a partial fix.

While it does now display taxonomy terms for which the user has 'update' privileges. You can't actually save those terms back to the database. I need to fix all those hard coded instances of checking for 'create' privileges.

Whoops. Guess this explain why one should never patch at 4am.

I will get this fixed soon, as I need it for a site this week. But, in the interim, I wanted to let people know that the patch doesn't completely work.

johnalbin’s picture

StatusFileSize
new3.13 KB

Okay, I think I've got this fixed proper now.

In addition to the work I specified in my last (partial) patch, I had to edit taxonomy.module's taxonomy_nodeapi and taxonomy_node_save.

taxonomy_nodeapi is called when saving a node and knows whether a node is being updated or created, but this info is not passed to taxonomy_node_save. It is taxonomy_node_save that checks taxonomy_access, so it needs to know whether it is updating or creating a node.

As I said before, the attached patch works with the 4.6 taxonomy.module that has already been patched with 4.6 taxonomy_access's taxonomy.patch.

keve’s picture

Status: Needs review » Closed (fixed)

Thanks, JohnAlbin.

I commited your patch to latest 4.6 version of taxonomy_access.module