To a first-time user of this module, it's not immediately obvious that you shouldn't enter values in for Allowed values, since with a normal select list, you would.

According to #1074914: Allowed values cannot be removed per list module limitations (core), you should be able to remove allowed values if you add them temporarily. However, if you decide to remove all allowed values and use any submitted value, you still get the error message.

Error message 'list_illegal_value" is given to users when Allowed values used. Not user-friendly.

Patch to follow.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cwithout’s picture

I've managed to change the error message to a more useful one like "Field: illegal value." rather than "list_illegal_value". I also added a message to the initial allowed values list that says not to add them unless you want to restrict values (since this isn't intuitive.)

I've also managed to get the form to allow for changing the allowed values even if they're in use, but even though it allows for changes, it produces error messages. I can probably get it fully working but not without a hacky solution.

That leads me to the question: Why are there allowed values *and* select list options? My initial thought was to simply remove the Allowed values fields from the form, which would be relatively easy, but then I spotted #824270: Improve allowed values support which indicates they're desired but "wonky". (I totally agree on the wonky assessment.)

I just can't see a use-case where you'd want to use allowed values. The entire concept of an "other" option would negate having allowed values. I can't think of a reason why you'd want to have a defined set of "other" values, which are hidden from the user. How would you use that in a way that wasn't completely frustrating to the user or couldn't be done with the normal select list?

The allowed values seem to be more of a hindrance to the ease of use of this module.

I expect most people run into the issue that I initially did in that they either think they're supposed to add allowed values like you would a regular select list or they think they test out the allowed values. Then when they realize that's not what they want it to do, they find out they have to remove all instances where the values are in use before they can delete allowed values.

So what do you think about removing the allowed values field? This could probably be accomplished simply by making those fields hidden on the forms.

cwithout’s picture

Title: Improve (or remove?) allowed values handling and error message » Improve allowed values handling and error message
Status: Needs review » Active
FileSize
2.17 KB

Minor error in that patch. Forgot a closing HTML tag in the form alter.

I'm going to make a patch that just hides the allowed values in case you want to go that direction. Post that in a bit.

cwithout’s picture

Here's patch to hide the allowed values field. Technically it removes some functionality, but it's functionality which no one in their right mind ought to want. (Mystery "other" values.)

I think it makes the module seem much cleaner without it. When I first installed it, I thought it was buggy because of the allowed values. If other people did the same as I did, it might be turning people away from using it.

cwithout’s picture

Title: Improve allowed values handling and error message » Improve (or remove?) allowed values handling and error message
Status: Active » Needs review
mradcliffe’s picture

Thank you for the feedback, cristinawithout! I am kind of exhausted this week after a big project's production update deployment, but I will take a more in-depth look at this (probably next weekend, maybe tomorrow).

cwithout’s picture

Title: Improve allowed values handling and error message » Improve (or remove?) allowed values handling and error message
Status: Active » Needs review

No problem. I just noticed realized that the form alter in #3 patch alters the select list for all widgets, so it'd need to check the widget before altering. Something like below.


/*
 * implementation of hook_form_alter()
 */
function cck_select_other_form_field_ui_field_settings_form_alter(&$form, &$form_state, $form_id) {
  if(isset($form_state['build_info']['args'][0]['widget']) && $form_state['build_info']['args'][0]['widget']['type'] == 'cck_select_other') {
    $form['field']['#description'] .= '<p>There are no field settings used by this widget.</p>';
    $form['field']['settings']['allowed_values']['#type'] = 'hidden';
  }
}

/*
 * implementation of hook_form_alter()
 */
function cck_select_other_form_field_ui_field_edit_form_alter(&$form, &$form_state, $form_id) {
  if(isset($form_state['build_info']['args'][0]['widget']) && $form_state['build_info']['args'][0]['widget']['type'] == 'cck_select_other') {
    $form['field']['settings']['allowed_values']['#type'] = 'hidden';
  }
}

I wasn't able to find anything in the API that handled getting args rather than directly accessing $form_state['build_info']['args'].

mradcliffe’s picture

FileSize
1.85 KB

I think this warning should be suitable enough. It's possible someone might know what allowed values they want to restrict the field to so I don't want to remove that from the initial field settings.

mradcliffe’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.