The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.(I'm using MYSQL, no other Access Control Modules)
When Taxonomy Access Control disables options from a Term Reference Field, it forgets to reset the default value.
For example, consider the Vocabulary Bird, with the Terms: Sparrow, Hummingbird, and Cardinal.
Consider user johndoe who (through TAC) is denied access to Sparrow. Consider a content type Article that has a term reference field called "field_bird" that selects a term from the Bird Vocabulary from a radio button list, and pretend its default is Sparrow.
If John goes to create his new Article, he's presented with the Radio Button list with the Sparrow option CHECKED, but DISABLED. If he's not allowed to select Sparrow, then the module should detect that and choose a new default value.
I've attached a patch to taxonomy_access.module to select a new default in case the old default is disabled.
| Comment | File | Size | Author |
|---|---|---|---|
| diff.patch | 428 bytes | shwin |
Comments
Comment #1
xjmSee also #1209154: Form UX: disabling vs. hiding disallowed terms.
I'm not sure about randomly picking the next value in the field as a default. That introduces unexpected behaviors. It would be better to simply unset a default value that is disallowed.
Comment #2
xjmSomehow the component was mis-set.
Comment #3
xjmComment #4
xjmWhoops.
Comment #5
joevansteen commentedI was using 7.x-1.x-dev and having trouble finding out why a taxonomy access control field was completely disappearing from my new node creation form (for a book page). After going around and around I ended up here... which seems like the best place to report my experience.
I had a series of values established for the vocabulary, but the author of the page was only allowed access to one vocabulary term, as I wanted to force that author to choose that term thereby limiting his options on creating new pages to only that term. I could trace the code being executed, but the TAC field in question was not being output as part of the web page. I'm not sure where the field was getting 'lost' or truncated. After review of this issue and playing some more, I found if I changed the field default to 'n/a' instead of the disallowed term, everything cleared up - the field is now displaying, and only the one term that I wanted is allowed (the other terms being 'inactive').
In my case, since I only had one term available for this author, I would have assumed that the default would have either been changed to 'no default' or would have became the available term. Since I changed it to 'n/a' it now works but comes out as a radio selection which still must be made on input, rather than being defaulted. Defaulting makes sense to me to save the user input keystrokes since there is no real choice. The other thing that makes sense to me is to hide the inactive selection options. I'd rather have them hidden than displayed since they aren't available to this author and they just generate unnecessary questions on the form.
Thanks for your work on this module! I'm finding it very useful for managing access rights the way I want to have them controlled. I also like the changes you made to the admin dialog by switching the radio selection to the combo boxes. I think it clears up the UI and makes it a lot easier to see what's going on.
Comment #6
xjm#5: Your issue does not sound related, although I'm having some trouble understanding the scenario. If you could open a separate issue, with a list of steps to reproduce and some screenshots of your configuration, that would be helpful. Note that a term reference field is automatically hidden if the user does not have access to any terms in it. Thanks! :)
Comment #7
xjmSee also #1339828: Disallowed default causes field to not appear. There's a patch there (soon to be committed) that allows users who can access at least some terms to edit options widgets on entity creation, even if they don't have access to the default value. The behavior on entity edit is unchanged.