Brainstorming: OptionList

[Kevin Benton]

Here’s a brainstorm I came up with due to a real need here.  I wanted to get
feedback before submitting a bug:

New field type proposal:  OptionList

Purpose:  To allow certain types of flags to be set, but have more than
binary operation (on or off).  This could potentially be used as part of a
custom fields implementation.

Concept:  Currently, flags may be set or not set in Bugzilla.  If an
administrator needs to have more of a radio type of functionality with logic
behind it, there is no method to implement that at this time in Bugzilla
without hacking up the code.

For example, after creating a third party gateway to Bugzilla, we now need
one of three possible states for a flag:  Off, VendorsCanSeeAllEntries, and
VendorCanOnlySeeOwnEntries.  Each of these is mutually exclusive in state.
When it’s off, no updates are authorized to go to third parties.  When
VendorsCanSeeAllEntries, third parties may see all comments made to bugs.
When VendorCanOnlySeeOwnEntries, each third party may only see entries they
made plus those made by internal people.  As it currently stands, in order
to implement this, it would require further customization of Bugzilla to
check to make sure that only one of the two flags is turned on – a feature I
feel would be wise to have added to Bugzilla proper.

Proposal:  Create a new flag type called an OptionList.  With an OptionList,
an administrator could tie the OptionList to a component and group just as
they do now with flags.  The difference is that an OptionList may contain a
list of choices users may make.  The OptionList may also specify a minimum
(forcing a choice), and a maximum allowable number of options selected (0
for unlimited, 1 to work like a radio, n to work like a select multiple
list) for the form to be accepted upon creation and/or editing.  Each
OptionList would have its own distinct name and potential values.  It would
also have an area to store Perl code to check and process the option once
created/edited/removed.  This would give the system administrator the
greatest level of flexibility without having to update Bugzilla code.

As I see it, some of this could also replace some of the existing fields
(enums) like Operating System and others.

Possible table definitions:

optionlists (
  optionlist_id mediumint(9) not null auto_increment primary key,
  optionlist_name varchar(255),
  optionlist_is_active bool,
  optionlist_allow_multiple bool,
  optionlist_perl_add text,
  optionlist_perl_edit text,
  optionlist_perl_delete text,
  optionlist_sql_add_trigger text,
  optionlist_sql_update_trigger text,
  optionlist_sql_delete_trigger text,
)

optionlist_items (
  optionlist_item_id mediumint(9) not null auto_increment primary key,
  optionlist_item_optionlist_id mediumint(9) not null auto_increment,
  optionlist_item_name varchar(255) not null default ‘Undefined’,
  optionlist_item_sortkey tinyint,
  optionlist_item_alt_text varchar(255)
)

bug_options (
  bug_id mediumint(9) not null,
  bug_option mediumint(9) not null
)

The optional Perl code would return a non-zero result if an error had
occurred while processing the option.  It would have access to all the same
values that the CGI is already using.  The optional SQL code could bridge
the gap for those who currently don’t have triggers available (not in MySQL
till MySQL v5).



---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management. 
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.