dhis2-devs team mailing list archive

["Laura E. Lincks" <laura.lincks@xxxxxxxxxxxxxxxxx>]

Public bug reported:

We've discovered a bug in regard to using an Option Set (at least in
regard to tracker capture forms.)

Version:
2.22
Build revision:
21878
Chrome Version 49.0.2623.110 m

We are using Tracker Capture to collect data for a simple survey (Survey
questions are set up as data elements.) All responses can range from 0
to 3, inclusive. I therefore set up an Option Set called 'Choices'.
Under Option Management I added 4 options: 0, 1, 2, 3. The data elements
are assigned to the 'Choices' Option Set.

I have a customized data entry form under a single Program Stage. The
'Choices' Option Set is available for every data element on the form.
When doing data entry, clicking the Option Set pull-down and selecting
an option with the mouse works fine. However, when using the keyboard
(our preferred method) I can tab to a data entry field, type one of the
choices (0, 1, 2 or 3), hit Enter and the value I type saves just
fine... with one exception: Every time I type '2', my selection is not
captured and the field saves a 0 on the form (and on the back end). The
only way to save the value 2 with the keyboard is to cursor down to the
'2' on the list and hit Enter. The other options in the pull-down list
do not require that the user cursor down to the option.

In my above example where I use an option set consisting of 4 numeric
responses, typing a '2' did not filter down to just the value of '2'.
Upon further inspection, it appears that when typing a value on the
option list, the control filters to the values which match that typed
entry along with the underlying uids of the individual options. So in my
above example, the number 2 was part of the uid of options 0 and 1, so
when I typed '2' in the option box, 0, 1, and 2 appear... (and unless I
cursor down to the 2 in the list, it will take the first option listed,
a 0 in this case.)

My fix was to delete and recreate the options until the system generated
uids without digits that would confuse selection of another option. Not
a perfect fix, but easy  enough to do in this small set of options.

Also note, that in this example, I now have an Option 2 which contains a
'4' in the uid. 4 is not a valid choice. But if I type a '4' the object
will select the value 2 from the list rather than reject the typed entry
as invalid. Actually, typing any character which is part of any Option's
uid will filter to that Option in the list.  I would think we would not
want the ability to filter selections by typing uid values.

** Affects: dhis2
     Importance: Undecided
         Status: New


** Tags: options optionset

-- 
You received this bug notification because you are a member of DHIS 2
developers, which is subscribed to DHIS.
https://bugs.launchpad.net/bugs/1567570

Title:
  typed Option Set entries filter too broadly

Status in DHIS:
  New

Bug description:
  We've discovered a bug in regard to using an Option Set (at least in
  regard to tracker capture forms.)

  Version:
  2.22
  Build revision:
  21878
  Chrome Version 49.0.2623.110 m

  We are using Tracker Capture to collect data for a simple survey
  (Survey questions are set up as data elements.) All responses can
  range from 0 to 3, inclusive. I therefore set up an Option Set called
  'Choices'. Under Option Management I added 4 options: 0, 1, 2, 3. The
  data elements are assigned to the 'Choices' Option Set.

  I have a customized data entry form under a single Program Stage. The
  'Choices' Option Set is available for every data element on the form.
  When doing data entry, clicking the Option Set pull-down and selecting
  an option with the mouse works fine. However, when using the keyboard
  (our preferred method) I can tab to a data entry field, type one of
  the choices (0, 1, 2 or 3), hit Enter and the value I type saves just
  fine... with one exception: Every time I type '2', my selection is not
  captured and the field saves a 0 on the form (and on the back end).
  The only way to save the value 2 with the keyboard is to cursor down
  to the '2' on the list and hit Enter. The other options in the pull-
  down list do not require that the user cursor down to the option.

  In my above example where I use an option set consisting of 4 numeric
  responses, typing a '2' did not filter down to just the value of '2'.
  Upon further inspection, it appears that when typing a value on the
  option list, the control filters to the values which match that typed
  entry along with the underlying uids of the individual options. So in
  my above example, the number 2 was part of the uid of options 0 and 1,
  so when I typed '2' in the option box, 0, 1, and 2 appear... (and
  unless I cursor down to the 2 in the list, it will take the first
  option listed, a 0 in this case.)

  My fix was to delete and recreate the options until the system
  generated uids without digits that would confuse selection of another
  option. Not a perfect fix, but easy  enough to do in this small set of
  options.

  Also note, that in this example, I now have an Option 2 which contains
  a '4' in the uid. 4 is not a valid choice. But if I type a '4' the
  object will select the value 2 from the list rather than reject the
  typed entry as invalid. Actually, typing any character which is part
  of any Option's uid will filter to that Option in the list.  I would
  think we would not want the ability to filter selections by typing uid
  values.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhis2/+bug/1567570/+subscriptions