Edit/delete terms permission per vocabulary

Catch, great job! I'll bookmark this issue and test the patch tomorrow.

Couple of things - since term objects don't contain the name of their parent vocabulary, only the vid, I've used that to differentiate the permissions instead of vocabulary->name - otherwise we'd be loading vocabularies on term pages just to check a permission... Since we have permission titles and descriptions now, this only affects the values in the database, and saves a query or two.

Another reason for doing this is that a vocabulary's name may change over time. If permissions depend on this name things may get very, very nasty.

I took a quick peek at the patch and it looks good so far. I suggest changing the drupal_set_message() so it can be used if a user wants to add multiple terms but isn't allowed to do this as well. This prevents pages from being flooded by messages if a user (accidentally) wants to add(/create) a lot of terms.

I'd use %vocabulary for permissions' titles and description. Also, we might want to think of a shorter message to tell the user he doesn't have permission to create new terms.

I know it's hard to make it shorter, but it's quite long now. I admit I haven't been able to come up with a shorter version as well, but we should try. Everything else looks superb from here!

What about "You have no permission to save the terms %terms"?

I don't have any real issue with the "no permissions" message that's currently in the patch, though it is long. We could possibly tweak this one, however:

Terms are entered by users by typing a comma separated list. Users may create new terms using this method (tagging) if they have permission to do so for this vocabulary.

Automatically match existing terms entered in a comma-separated list. New terms in the list will be created (for users with the appropriate permissions).

The only problem with this is that, AFAIK, the autocomplete is really only going to match the first term entered in the list.

The only problem with this is that, AFAIK, the autocomplete is really only going to match the first term entered in the list.

Nope, it works for all terms :-)

So it does. My bad.

Looks like a terrific patch to me. I code reviewed but did not test.

What about adding a view $vocabulary permission? A user would need this permission to view the /taxonomy/term/[tid] pages.

By the way: personally I would not use variables within strings like
echo "create terms in $vocabulary->vid";
IMO, putting them outside the string is more readable, especially when using syntax highlighting, so I'd change it to
echo 'create terms in ' . $vocabulary->vid;

I know, but it still makes more sense to me not to put variables within strings. Actually, this should be in the coding standards... :-P

IIRC usernames are only displayed as links if the user has permission to access user profile. Perhaps we could implement something like that? But indeed, if we're going along that way, this probably requires a separate issue.

subscribing.

After looking at the rejected.png image, I see a usability issue waiting to happen. Since I don't see an image for the actual form prior to submission, I assume that it hasn't changed. Maybe users without the proper permissions, shouldn't see the actual vocabulary select/dropdown on a /node/*/edit form? This way they won't have the chance to enter in any terms where they don't have the permission to do so, I think we can do it two ways:

1) Remove vocab from form if user does not have access to it.
2) Disable the input field, so the user can see it but can't edit it. (can we do this without JavaScript?)

How is the required option going to be handled? Since giving users a "create terms for X vocabulary" permission, I think it is in the best interests to make the required option based on what user is has access to create terms. A simple breakdown of what not to happen would be:

1) node allows authenticated users to edit it
2) node has multiple vocabularies associated with it, with only one vocab that is editable by auth user.
3) user edits it and attempts to save node
4) node fails validation since a required vocab was not filled out since user does not have access to it.

BTW, I love this idea to begin with. I always wanted to create an "admin-only" taxonomy to categorize content without a) messing with hook_form_alter() and b) allowing users to see "internal" vocabularies.

All roles should be able to select terms from a required vocabulary.

My point was that if you created a required vocabulary, assigned it to "article" and only allowed UID1 to create/edit terms for it, should the node still validate and save if you allowed authenticated users node edit permissions?

Hi Catch,

Check this out

http://drupal.org/node/323490#comment-1733196

Just found it, sg similar for Taxonomy Manager (how about that in core? :)) )

Yes, we badly need this. Tagging.

Anyone up for re-rolling?

Looks good to me, and this functionality is basically already covered by tests.

Also fixing issue title, because "create" is deferred to a point in time where we find a solution for how to handle term autocomplete widgets...

Alright, I'll let this one slip in. Committed.

applying this patch to my drupal 6.15 doesn't work and causes errors in permissions page!
what should I do?

You shouldn't apply this, as this patch was written for Drupal 7, but will be postponed until Drupal 8.

// Sorry for moving this to D8 again! Guess I wasn't fully awake...

This patch went into D7 already.

dragon2000: There is a new module PermMill for Drupal 6.x, which allows you to define fine-grained permissions on a per-page basis. I found this very usefull for splitting taxonomy permisions. Try http://drupal.org/project/permmill

Just for people stumbling upon this issue and are wondering where the "create" permission is being discussed further: #1034600: Split Taxonomy permissions into 'Vocabulary' and 'Terms'