You must have one left over at least.
When you edit a twiki form you can't de-select a checkbox selection (or any multi-value form field) and have NO selection.
How to reproduce:
- define a form with a checkbox selection in it that is not mandatory
- create a topic and attach the form.
- initially no options are selected, so select one and save.
- edit the form again
- the selected value is there as expected. Now de-select it so that no checkboxes are switched on
- save
- edit again
- the selection is back again
You can only get rid of a value by selecting another one. But
you cannot have the empty selection back anymore.
The cgi query object will not transmit any parameter to the engine
which will in turn
MERGE the values into the meta data section.
So despite my will to de-select the form value (having none) I will
always get the old one back.
Is there a fix for that?
--
MD
Reported also in
TWiki:Support/BugInForm and with test case
TWiki:Sandbox/FormBugTest
You can uncheck all but one checkbox.
--
PTh
I am afraid that this is going to be tricky. According to what I have found, today's behaviour dates back to june 2005, r4421,
TWiki:Codev.SaveContentWithoutEdit (though the actual lines have changed somewhat since then). And it is documented in
TWiki:TWiki.TWikiScripts#save. The problem is that apparently nobody saw the implications on checkboxes.
Since the topic and the SVN history of
Form.pm
are lengthy, let me summarize what I think was the idea of the change, and why it fails with checkboxes:
In
TWiki:Codev.SaveContentWithoutEdit the idea of directly calling the
save
script without having to go through an
edit
form has been discussed. One of the use cases was to write links pointing to
save
, and passing parameters directly after a
?
. For that use case to work robustly, fields which were present in the topic but not in the query had to be left untouched.
Exactly that is where checkboxes behave differently than other
input
elements: If a checkbox is checked, a
name=value
pair is passed to the program. If it is unchecked,
nothing is passed. Checkboxes do not know a special value for "off" or "unchecked", and it is part of the HTML spec that unchecked checkboxes leave no trace in the request. The
save
script can not know whether the checkbox was, well, just missing, or whether it was deliberately set "off".
I can only think of something which is more a workaround than a fix: When a checkbox (or a set of checkboxes) is being rendered for editing, add an additional hidden control with the name of the checkbox and a value of
""
(i.e. the empty string), or some other dummy indicator.
I would be glad if someone came up with a better solution and revert my checkin...
--
haj
This looks like a sensible workaround to me.
could someone check if other types are OK? Such as select with empty value...
--
PTh
Good point! I thought it wouldn't, since a simple select always is coming with a value, but that isn't true for
select+multi
where one
can deselect all values which makes the parameter vanish from the query. This needs another checkin. And it is another proof for Crawford's observation that an UI test environment would come in handy.
BTW: The current fix does not handle the case where one wants to deliberately define an empty value as a
select
(or
checkbox
) value. So don't do that
--
haj
4.1.0 released
KJL