#1857 - Field options

Identifier #1857
Issue type Feature request or suggestion
Title Field options
Status Completed
Handling member Chris Graham
Addon core_fields
Description Add field options for a field (needs doing for both CPFs and catalogue fields).

It is done via a simple line input, which has comma-separated options written into it.

There'll be no specific UI for configuring it all, it will involve hand-typing (a UI would be hard as to make it user-friendly we'd need to code it up with pre-knowledge of all options, and what field types each could apply to).

Supported field options would be...

Multi-list inputs:
- custom_values=no|single|multiple
- widget=multilist|vertical_checkboxes|horizontal_checkboxes
- show_unset_values=off|on
- dynamic_choices=off|on
Date inputs:
- min_year=?
- max_year=?
Multi-line inputs:
- num_required=?
- cms_type=line|codename|integer|float|email
Text-block inputs:
- wordwrap=off|on
- wysiwyg=off|on
- rows=?
Upload inputs:
- filetype_filter=?
List inputs:
- custom_values=no|single|multiple
- widget=inline|dropdown|radio
- list_size=?
- auto_sort=off|frontend|backend|both
(Misc):
- input_size=regular|fullwidth
- maxlength=?
- html_type=text|password|number|email|tel|url|color

Not all options apply to all field types. Many are very specific. I have roughly showed above what field types would support which.

Extra notes:
- Setting custom_values to a value other than 'no' turns a multi-list input into a combo box
- Setting dynamic_choices to 'on' feeds all existing user-selections for the field back in as possible choices in the input list for future users (i.e. the input list is a combination of the list specified in the catalogue settings, and also subsequent user-inputs)
- Setting show_unset_values to 'on' results in the entire selection list being shown on the frontend, with crosses or checks next to each item saying whether it is selected. Normally it would just list the selected values alone.

Some of the existing multi-list field types would be merged together, and then differentiated only by field options. e.g. we don't need separate field types for whether a multi-select list is used or checkboxes, as that is just the 'widget' setting. This will make things much more intuitive, as it separates considerations of data modelling from the concerns of input UI design.
We would write a conversion script to switch out existing usages of the dropped field types.

A new fields tutorial would be produced. It would consist of a table with a row for each field type. Each row would include:
- The human name of the field type
- The codename for the field type used internally (makes things much clearer for programmers)
- The supported field options, including what the defaults of each option is
- A screenshot of the input UI
- A screenshot of the frontend UI (or multiple if the 'widget' field option is supported by the field type)
- Supported formats for inputting the default value
- List fields have options delimited by "|", with the real default value coming first
- Date fields may have a default value of 'now', which works dynamically
- AUTO_INCREMENT default value
- RANDOM default value
- ... ?
- Storage format, and notes how search is impacted (e.g. a date is stored as a textual string, and multi-lists are stored as a string with each selection written on its own line)
The existing catalogues tutorial would link to the fields tutorial, as would the tutorial that covers CPFs. Any fields documentation in the catalogues tutorial would be merged in.
Steps to reproduce

Funded? No
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".

Rating

Unrated