Page MenuHomePhabricator

radio button fields produce superfluous "None" field and do not obey query strings
Closed, InvalidPublic

Description

I previously reopened this bug in error:

https://bugzilla.wikimedia.org/show_bug.cgi?id=24111

And created this bug in error also:

https://bugzilla.wikimedia.org/show_bug.cgi?id=32421

I have now pinned down the bug that caused those mistaken reports. Triggering the bug causes similar effects to those erroneous bug reports:

Semantic Forms radio button fields with the parameters "mandatory", "values", and "default" still usually produce a superfluous "None" button, which is selected by default, even if another value should be selected by default. Even #formlink query string parameter preloaded selections are not obeyed sometimes.

I took the day to prepare a demo, which I will post after I rename it to the bug number that this report receives.


Version: unspecified
Severity: normal

Details

Reference
bz32580
TitleReferenceAuthorSource BranchDest Branch
requirements: version bump eventutilities.repos/data-engineering/mediawiki-event-enrichment!77gmodenaversion-bump-eventutilitiesmain
make: version bump mediawiki-event-utilities.repos/data-engineering/eventutilities-python!84gmodenamediawiki-event-utilities-version-bumpmain
requirements: version bump eventutilites-python.repos/data-engineering/mediawiki-event-enrichment!73gmodenaeventutilites-python-version-bumpmain
eventutiliites: version bump to 1.3.0.repos/data-engineering/eventutilities-python!81gmodenaeventutilities-version-bumpmain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:06 AM
bzimport set Reference to bz32580.

The query string is ignored when editing an existing page - I think that's the cause of the "bug" you're seeing. That's done on purpose, so that the form won't overwrite content without the user's knowledge.

OK, then the proper way to do that is with #autoedit, correct? If so, then that would mean the query string feature of this bug report is invalid, but maybe I should test #autoedit at some point in the future to see if it has any quirks.

The rest of the bug report with the "None" field appearing when it isn't supposed to is still valid though, right?

I changed the way I report bugs to make sure they're more likely to be valid, easier to reproduce, and hopefully better isolated, but it takes a lot more time dedicated to doing trial and error tests to pin it down. Let me know if this method is working out better, or if it needs adjustment.

Yes, #autoedit is the way to automatically modify existing pages.

No, the fact that "None" shows up is the correct behavior, since the value of that field in that page is, in fact, blank/none. Since this was the only other part of the bug report (I wasn't sure about that), I'm marking this as "invalid".

I just tested the creation of a new page again, which should obey the mandatory default value of "3", and it succeeds in eliminating "None" and preselecting "3":

http://www.coincompendium.com/wiki/index.php/Special:FormEdit/Bug_32580/CreateTestPage

I may have conflated the edit and the create default behaviors as being the same, when in fact it appears they are supposed to be different, as you pointed out, if an existing page being edited does not have a value assigned yet.

Although that was confusing for me when creating fresh pages as a developer, I think as a user it is a sensible default to do nothing instead of wedging in a default if, for example, that default is added at a later time.

I'm disappointed that I spent so much time on this, but I think it was a good exercise for producing bug reports with a demo that shows behaviors that can be quickly evaluated as either correct or incorrect.

Where I ran into trouble was in creating the test page:

http://www.coincompendium.com/wiki/index.php/Bug_32580

It originally had no template {{Bug 32580}}, which produces the error "Warning: This page already exists, but it does not use this form." - claiming that it the page does not use the Bug_32580 form:

http://www.coincompendium.com/wiki/index.php/Bug_32580_sans_form_template

So, I guess we're at an edge case where we're trying to make a preexisting page editable with a form that has a radio button field, but has no presently defined value for the field.

Perhaps the real bug/enhancement is that the error message should be omitted, and the radio button should display a "None" field, while also preselecting the specified mandatory default as it currently does?:

http://www.coincompendium.com/wiki/index.php?title=Bug_32580_sans_form_template&action=formedit

The error message saying that the page "does not use this form" is confusing because it is incorrect, at least in this case, and probably the reason I managed to conflate cases where "None" is supposed to appear, and when it isn't. I seem to have expected that it would be supposed to appear, without a form error message, while the default value is preselected.

Would that be a better behavior for the radio button fields when a form is added to a page that did not use it previously? Perhaps "None" should not appear as an option when the field is mandatory, which is the current behavior, but maybe there's a good reason why the error message should also be retained too?

Hi - I didn't really understand the question, but if you think you've found a unrelated bug, feel free to create a separate bug report for it.

The question is whether the error "Warning: This page already exists, but it does not use this form." is appropriate on pages that are correctly set up for the form but do not have the form's template applied yet. And, if it would be correct to have a "None" selector for radio buttons on those pages, even if a default is specified, because there is no current value, as you described when you said:

(In reply to comment #4)

No, the fact that "None" shows up is the correct behavior, since the value of
that field in that page is, in fact, blank/none.

I suspect there might be a good reason for the current behavior. If not, I'll make a new bug report.

I think the warning is appropriate, yes. And as I said before, I think the "None" is correct behavior.

OK, what is the warning appropriate for? Why is the "None" correct behavior when there's no value assigned for its field, but not when there's both no value, and no template?

I'm guessing that set of behavior deals with cases that I'm not familiar with.

Well, you used the phrase "correctly set up for the form", but I don't know what that means in this context - if the page doesn't have the right templates, then it's not "correctly set up for the form".

"None" is appropriate because it reflects what's already in the page - the aim is to not have the form override a value without the user knowing about it.

In this case, the default form is set up using the "based on category" method:

http://www.mediawiki.org/wiki/Extension:Semantic_Forms/The_%22edit_with_form%22_tab#Based_on_category

with the "Has default form" special property on the category page:

http://www.coincompendium.com/wiki/index.php/Category:Bug_32580

It looks like Semantic Forms wants to see the template already in place too, which might not be the case if the page was created without a form. Also, that aspect doesn't appear to be mentioned in the docs, so I'm not sure that it should check for the template when one of the methods to specify the form to use is already correctly implemented (unless I've overlooked something).

SF can:

  • create a page and simultaneously add a template to it
  • edit a template that's already on a page
  • add a template after the page was created some other way (manually in this case)

Giving a warning message may not be the right thing to do when everything seems to be functioning correctly in the last circumstance listed above.

Well, the Semantic Forms philosophy is that categories should only be added to pages via templates.