The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.First, is there some way to change the owner of a term? I can't see anyway to do this.
Second, here is my use case:
A taxonomy will have certain terms available to all users (e.g., apples, oranges). Each user can also have their own terms available just to them (e.g., User A: black, white; User B: eggs, bacon).
So when adding new content that uses this taxonomy, User A should have access to "apples, oranges, black, white" and User B would have access to "apples, oranges, eggs, bacon" and User C (who hasn't added any terms) would just have access to "apples, oranges"
Is there some setting that I'm missing somewhere that would allow a term to be "public" and available to all users?
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | public_terms-2635012-7.patch | 8.95 KB | trobey |
| #6 | public_terms-2635012-6.patch | 5.27 KB | trobey |
| #4 | Screenshot from 2015-12-16 10:08:40.png | 83.28 KB | trobey |
Comments
Comment #2
trobey commentedIf you go to admin/structure/taxonomy/user there are settings for new users and existing users. Expand the existing users and there is a setting for the user with the base set of terms.Once this is set you can create these terms for all the existing users. If you check the box for new users then when a new user is created they will automatically have these terms created for them. This is a bit more flexible than having a core set of terms since once they are cloned you can change them.
As far as changing the owner of a term, there is no user interface for doing this but if you are comfortable editing a database table then just change the uid in the user_term table.
Comment #3
jemisond commentedSo if I understand correctly, given the scenario I gave above, the following would occur:
- apples and oranges would be cloned (copied) to Users A, B, and C.
- Users A, B, and C can rename their versions of apples, oranges to something else.
- User D gets added, and he gets apples and oranges cloned for his account.
What if Admin later adds "pears"- I assume pears is not automatically cloned to all the other users?
And if Admin renames apples to "crab apples", all the cloned apples remain as apples?
For our case, we didn't want users to be able to change the default terms, but that may not be a deal breaker. But depending on what happens in the questions I ask, it may not work for us. Also, with plans for tens of thousands of users (and hopefully more past that), having copies of all the default terms may not be the right direction for our situation...
Comment #4
trobey commentedThere may be another possibility. If you add a "Private term reference" field to a content type. The you get the attached field settings. There is a setting for the vocabulary to use for this field. There also is a setting for the users. There are just two options here: All and Owner. All shows all terms so the node can be tagged with any user's terms. Owner limits the terms to just those owned by the user. There has always been the possibility of adding to these options but there has never been a situation that made sense. But we do not want to have thousands of options (say all the users) here. Also, this issue is marked for Drupal 7. Most development is on the code for Drupal 8. Any changes to code for Drupal 7 should not impact the large number of Drupal websites already using this code.
Comment #5
jemisond commentedSo the results for the different settings would be:
All
- User A: apples, oranges, black, white, eggs, bacon
- User B: apples, oranges, black, white, eggs, bacon
- User C: apples, oranges, black, white, eggs, bacon
This seems to have the same effect as giving everyone access to add terms to that taxonomy
Owner
- User A: black, white
- User B: eggs, bacon
No one gets access to apples, oranges unless they manually add those terms to their own list. (Or have them automatically cloned, which doesn't work well as I explained in our use case.)
So it looks like the best path is to go back to our original idea of adding a uid field to the vocabulary (that gets assigned by a rule when created) and use a view to pull the correct terms for that user- the uid field is that user's or 0 (for default terms). We were hoping to have a solution where users could create terms on the fly when they add content (like with a Term Reference filed with a tagging widget) instead of making them add a new term on a different form then adding the content with that term.
Comment #6
trobey commented@jemisond: Please review the patch and see if it looks like it will work. Make a vocabulary private and then add a Private term reference field with the select list for the widget on a content type. In the settings under Users you will now see roles appear. In a separate window create a role 'Public terms' or something similar and add any users to this role whose terms should be public. Have that user create a few terms in the private vocabulary (you can use Masquerade to allow yourself to do this). Now refresh the first window and the new role should appear. Select it. Then create a new node of that content type and check the field. You should see your terms plus any users that belong to the selected role.
I think I still have to add some code for the autocomplete.
Comment #7
trobey commentedAn updated patch with code for the autocomplete.
Comment #8
jemisond commentedWorks beautifully in my testing- thank you!!!
(For some reason, the patch wouldn't update tests/private_taxonomy.test (it said it couldn't find the file)- I had to copy the file up a directory.)
A couple of minor issues:
1) The owner of the term appears in parenthesis after each term- possible to not display?
2) If the site admin (or the user adding the default terms) adds content, he can only see his (and any default) terms, not everyone's terms.
On further reflection, I guess I can see one argument for keeping #1 as it is- if a user creates a term, then the default term adder adds the same term, there would be no way to distinguish between the two on the user's list. So maybe we will just do something like create a user called "Default" and use that to create the default terms. For #2, after the initial setup, the default user probably won't be creating new terms, so probably not an issue- can always check the master list of taxonomy terms from the Admin menu first. So I guess not really issues after all...
Anyway, mucho thanks again for all the work on the patch!!
Comment #9
jemisond commentedOne followup issue- I didn't check before the patch, but after the patch, anonymous users could not see views that used any taxonomy terms, even if the vocabulary wasn't set to be private. (Kind of a bad thing when that constitutes about 90% of your index page content... :) )
I gave anonymous users the "View private taxonomies" permission, and everything looks okay now.
Comment #11
trobey commentedPatch committed and new release created for Drupal 7. This will need to be ported to Drupal 8.
The owner of the term is necessary unless all terms belong to the current user. This is because it is possible for two users to have the same term with different term IDs. It is necessary to provide a way to distinguish between the terms.
Access to public vocabularies should not be changed by Private Taxonomy. If this is happening it probably is a bug. private_taxonomy_query_term_access_alter() restricts the access and it tries to figure out if the vocabulary is public and return. It is possible that the query does not follow "standard" queries and somehow bypasses these checks. It would be good to figure this out but I do not have enough information to duplicate the problem.
Comment #12
trobey commentedPorted to Drupal 8.