Disallowed default causes field to not appear

Is it possible that your code to fix http://drupal.org/node/1214660 is causing some conflict here? In my case, there is only one option available and there was a default supplied, it's just that the default isn't the option that was left. Just a thought ...

Well I certainly don't promise they will all be like that ;-)

I appreciate your work maintaining the module.

xjm,
FYI. I've been playing around with this a bit. I've found that if the number of values allowed (Figure 10 in the PDF) is changed from 1 to 2, the field no longer disappears. This changes the option from a Radio selection to a Checkbox selection.

Edit: After posting this I went back and looked at http://drupal.org/node/1214660 again. I then found four places in the taxonomy_access.module where you have the code
$element['#access'] = FALSE;
and I commented them out one at a time. When I had only the last one, on line 1760, commented out, the problem was fixed and the field re-appeared.

Edit: The logic of the code at this point repeats the logic of at least one of the other points, but I'm unsure of its validity. If the number of disallowed defaults is greater then the cardinality- why would this disallow the field? The other two tests check to see if there are no allowed terms, that makes sense. By what is the logic of the test against the disallowed defaults?

xjm,
Then you have a very different concept of 'default' than I do. In my world, a default is a selection that will be made automatically unless I change it to some other selection. You have unilaterally determined that even if another selection can be made, the defaults cannot be overridden by the other options that are available for selection by this user. Those aren't defaults, they have now become mandatory selections!

That is exactly what is happening in the case I presented. There is only one option available (radio selection). There is a default preselected: which happens to be the most likely selection in most cases. However, for authors or editors who are not allowed to make that selection, the code is forcing them to accept the disallowed default - and then the edit rejects their entry because the default is not allowed!

I can obviously shift to 'no defaults.' However, my thought is that you have changed the concept of default here to a mandatory selection. If that were the case, why bother having the other selections at all? Just force the selection and make the field hidden all the time.

Edit. I appreciate that if the default values are left turned on and cannot be changed then the form will not validate. However, my concept is that 'disallowed defaults' should be turned off. If they are disallowed for this user, then the user should not be allowed to create a form that turns them on, by intention or by default.

Sorry ;-(
I wasn't trying to be over-bearing ;-)

First, yes, I think when we talk 'default' we must be talking about node creation. That is the only time the values are 'default' selections. At that point they are proposed, potential values, not already selected and established values. That is why I originally brought up the issue in the context of http://drupal.org/node/1221548.

In the case of node creation, I think the user must be thought about as 'adding' the term. There is no previous node, so there can be no previous value to the field. Assuming the default specification as a previous value presumes a field before the node exists.

The author of http://drupal.org/node/1221548 proposed that in the case of a conflict, a new default be selected. I agree with your hesitation on that. I think it could led to the inadvertent selection of an arbitrary default, which in some cases might be a significant error. What I think is better, is to simply remove the disallowed defaults from the default selections. If this removes all defaults, so be it. If the field is not required, it may end up that no value is entered. But if it's not required, there is no foul there. If a value is required. The validation will force the user to make a selection. If some default values are not removed, those will remain as valid selections.

I see no need or requirement for priorities. Disallowed values are simply removed. Whatever remains, remains.

The only 'problem' I see is if all values are removed. That is a case you have now also. But still, disallowed defaults should be removed. If that results in an empty field, that would, IMO, be correct. If the field is optional, it loads empty. If the field is required - a validation error occurs. In that last case I believe the error belongs to the form designer - who should have tested for that case (requiring a field that the user can not provide).

Edit. Creating while you were posting. I think we're on the same track.

Re #8

If you 'strip' the disallowed terms won't you run into trouble in terms of http://drupal.org/node/1209154 Form UX: disabling vs. hiding disallowed term

This might eliminate terms that are needed as conceptual references.

What makes sense to me, is to take them out of the list of defaults (i.e., turn the 'off' as selected items). Then, make the change I suggested in the tac_create.js, the one line change to insert a 'tac-disabled' class statement on the enclosing div. Then leave the CSS change up to users to implement. If I implement the change, it makes the disallowed terms go away. If someone else needs them for context, they are still on the form.

Looks good to me. However, there is a dpm() function call still in there that needs to be removed.

Thanks! :)

xjm,
I'm having some strange side effects now after having implemented the patch. As an administrator, if I go to 'manage fields' for any of the content types that inlude my taxonomy access terms, and then I go to 'edit' the field I get an error page:

The website encountered an unexpected error. Please try again later.

Editing other fields on the content types is okay. And the error happens on each taxonomy access term on each content type where they are defined.

However, I'm not getting an error in my PHP log, so I'm not sure what's happening. Could you new code be getting called from somewhere during the 'manage fields' process and getting tripped up?

Edit. When I revert back to the old module, the error goes away!

Re: #19 - No stray debug code, basic function works as before, but also has same problem as before: 'Manage fields' edit for taxonomy_access fields throws undefined error.

Re #22, No stray debug code, intended function works and side problem with 'Manage fields' edit is gone. I can't speak for other types of usage, but from where I'm at it looks good. I will report anything else that I notice, but it looks clean and addresses the problem as reported.

Thank you! You did a lot of work here. I appreciate your efforts. And, I appreciate the lesson I received in both some PHP functions I hadn't seen before and in Drupal behavior. You've taught an old dog a few new things today :)