This module is great, but lacks a functionality I should be using: allow arbitrary strings to be entered and still have autocomplete working. The attached patch (rolled against today's -dev) adds a new checkbox called "Accept unlisted strings" to the widget setup form (?q=admin/content/node-type/$node_tpye/fields/$field_name), which is unchecked by default. If it's unchecked, everything works as usual. If it's checked, arbitrary strings can be entered as there is no validation (and no checking of #default_values), but the autocompletion still works.

Use case: there are various authors of publications at a university department: colleagues (content type: "colleague") and outside authors (they don't have any content nor content type). Both colleagues and outside authors should be allowed as authors of a publication (content type: "publication"). We can't use a nodereference (as outside authors don't have a node, according to customer's requests). The authors listed in arbitrary order, both colleagues and outside authors mixed up (thus we use an unlimited multivalue textfield), but names of colleagues should be displayed as-is. To ease the correct input our customer asked for autocompletion on colleague names, but still wants to be able to enter outside authors - so we forged the attached patch, which solves this scenario.

A new stable version (preferably with this patch attached) would be gladly welcomed.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

markus_petrux’s picture

Status: Needs review » Needs work

It looks like something useful. One thing I see in the patch that needs work. The autocomplete for allowed values widget is available for Text, but also for Number fields. However, this new option should only be available for Text fields because we cannot store the non-listed values as numbers.

[EDIT] Another thing that I'm not sure how it is solved is... when this new option is enabled, the autocomplete should provide candidates from existing field values as well as values from the allowed values list.

Boobaa’s picture

I forgot to mention that this feature only kicks in when using the allowed values list, but have nothing to do with existing field values. And yes, you're right, to be honest I haven't tested it with Number fields (yet) - but it should not be quite difficult to filter out these as well.

markus_petrux’s picture

Here's another approach that you could try without altering this module.

Try with an autocomplete for existing values widget. This will bypass the validation of the allowed values list. Then, using jQuery, replace the autocomplete path of the form element with your own. The menu callback of your autocomplete element could provide values from an arbitrary list based on something the site administrators can maintain somewhere else, such as users, taxonomies, nodes, ...

If we have to modify the module, then I think we need an additional option to define if autocomplete candidates are restricted to allowed values list, or can come from both sources (allowed values list and existing values).

markus_petrux’s picture

Status: Needs work » Closed (won't fix)

I'm not planning to add the suggested feature because a) it will complicate things here, and b) there's an alternative approach to get the same result, as outlined in #3.

cels’s picture

anyway, it's a good idea for text

[edit]

I test it; the "additional option to define if autocomplete candidates are restricted to allowed values list, or can come from both sources" adds a nice feature and makes it grow the module functionality.

I'm thinking of coding for internal development.

cels’s picture

the patch for the 6.x-1.3 version (after the security update)

SchwebDesign’s picture

thanks for posting this patch, this helped me a lot!!

SchwebDesign’s picture

well as excited as i got about this, i tried the patch from #6 above with my Autocomplete widget for allowed values and checked the checkbox for the relevant text field, but when testing and attempting to save node, i get [the fields name]: illegal value.

Has anyone else had problems with this? Has anyone else gotten this to work?

amaisano’s picture

I am also having problems with the patch in #6, patched against the 6.x-1.x-dev version. Everything seems to work until I try and submit a string not on the Allowed Values list, which causes the same error the SchwebDesign noted in #8.

If it helps, I am applying this to a CCK Plain Text field that is optional, and part of a multi-group. I have CCK 6.x-3.x-dev.

Is there something I should check in the database itself? There were no updates found when running the update.php script, so maybe something must be done manually?

Or perhaps we need to recreate the CCK field we want this working on from scratch?

UPDATE

I created a fresh CCK Plain Text field, 1 value, with the same settings above, *not* in a multi-group, and received the same errors, so creating a fresh field doesn't work, nor does not having it in a multi-group.