[dev.icinga.com #5967] Automatically submitting form elements can cause a controller to process the form

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/5967

Created by jmeyer on 2014-04-08 12:01:33 +00:00

Assignee: tgelf
Status: Resolved (closed on 2014-06-23 11:35:04 +00:00)
Target Version: 2.0-6
Last Update: 2014-06-23 11:35:04 +00:00 (in Redmine)

---

An element that is auto-submitting its form causes a usual POST/GET being made. A controller cannot differentiate automatic or manual submits. The only distinction made is whether the form's data is valid or not. This is fine as long as there are missing entries in the form, but once all entries are made and an auto-submitting form element is changed, the controller processes the form's data.

Example form: Preferences

Changesets

2014-06-20 12:32:22 +00:00 by tgelf 916c9c0

forms: fix isSubmitted

Implementation made wrong assumptions. A form is submitted when the
submit button has been pressed. It's value is then filled, it also
is when you're just pressing "RETURN". RETURN triggers the FIRST
submit button in a form. This way we are also able to find out which
form button has been pressed.

Current implementation is still poor, however isSubmitted works as
expected right now - and so does autosubmission.

fixes #5967

2014-06-23 11:31:34 +00:00 by tgelf ba9a633

Web\Form: relax form submission check

We have to live with some badly designed forms right now. Some have
submit buttons but don't know about, others don't have such but link
to foreign controllers fiddling with the form and adding different
button AFTER the form got submitted - it's a mess.

Relaxing the submission check to "just check whether btn_submit has
a value" fixes most of this. However I do not consider this being a
solution for the long run.

fixes #6423
fixes #5967
refs #6540

2014-06-23 13:46:15 +00:00 by tgelf 1efd1d1

GeneralForm: replace ignorant button

It makes no sense to add submit buttons without telling the form
that there is such, especially in combination with autosubmitting
elements.

refs #5967

---

Relations:

• relates #5967
• relates #5967
• duplicates #5967
• blocks #5967

[icinga-migration]

Updated by tgelf on 2014-04-17 16:39:16 +00:00

They should be able to distinct this based on button values. Expected behaviour:

• Button clicked or "pressed" on keyboard: only that button should carry it's value
• Form submitted by pressing RETURN/ENTER the active button should be the first button in this form (if any)
• Autosubmission: no button should be selected

Forms/controllers should make their decisions based on the button chosen by this rules. If JS doesn't perform like this, the bug lies there.

Regards,
Thomas

[icinga-migration]

Updated by jmeyer on 2014-04-30 11:16:25 +00:00

• Status changed from New to Assigned
• Assigned to set to jmeyer

[icinga-migration]

Updated by jmeyer on 2014-04-30 11:57:41 +00:00

• Status changed from Assigned to New
• Assigned to deleted jmeyer
• Target Version changed from 140 to 2.0-3

[icinga-migration]

Updated by mjentsch on 2014-05-28 16:29:01 +00:00

This issue is probably caused by our enableAutoSubmit function in our Form class. It will simply add the JavaScript $(this.form).submit(); and does not use the class autosubmit, which is intended for that purpose.

[icinga-migration]

Updated by elippmann on 2014-06-01 12:23:19 +00:00

• Target Version changed from 2.0-3 to 2.0-6

[icinga-migration]

Updated by mhein on 2014-06-02 13:43:00 +00:00

• Assigned to set to mhein

[icinga-migration]

Updated by mhein on 2014-06-03 11:00:46 +00:00

• Assigned to deleted mhein

[icinga-migration]

Updated by tgelf on 2014-06-20 12:40:03 +00:00

• Status changed from New to Resolved
• Done % changed from 0 to 100

Applied in changeset icingaweb2|916c9c027e78bdbfbafd4b484412c4dcd37ec068.

[icinga-migration]

Updated by jmeyer on 2014-06-23 07:07:36 +00:00

• Status changed from Resolved to Assigned
• Assigned to set to tgelf
• Done % changed from 100 to 50

This is not fully fixed. Select boxes can still cause the controller to process the forms data. (e.g. general configuration, preference type, don't store preferences)

[icinga-migration]

Updated by tgelf on 2014-06-23 07:27:37 +00:00

• Done % changed from 50 to 90

Try to set a submit label:

$this->setSubmitLabel('Save Changes');

Unfortunately forms lack basic understanding of how HTML forms really work. You only know whether a button has been pressed by checking it's value. If it has a label but the form doesn't know about that's "unfortunate".

Setting the above in your form's create method should fix your form, letting base form "know" it's default label would be "slightly" better.

Best,
Thomas

[icinga-migration]

Updated by tgelf on 2014-06-23 11:35:04 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 90 to 100

Applied in changeset icingaweb2|ba9a633b735905fe319fbc439aa8e818b58a82e8.

[icinga-migration]

Updated by jmeyer on 2014-08-12 08:17:44 +00:00

• Relates set to 5525