Since the reset-form functionality got moved into the header tools in
commit 046ec35 ("fix #5277: move reset button into window header
toolbar") we can unconditionally set the initial buttons, as those
will always just contain the submit one now.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The 'Reset' button, which can be used to reset the form to its
original values when editing an existing resource or property, was
located at the right to the submit button since its initial addition
(before the git epoch started at Proxmox).
As it had the exact same form and color as the 'OK' submit button, it
is easy to press by accident, which then resets the pending changes
one wanted to submit – while not catastrophic it's just needlessly bad
UX.
As this UX-mishap is something one gets used too relatively fast,
especially as developer due to frequently opening such dialogues to
test changes, its something that mostly newer users will run into.
Luckily one took the effort to actually open an enhancement request,
providing ample resources to underline their point.
While there where quite a few proposals to improve this, most of them
had some (smaller) disadvantage (e.g., potentially jumping location,
confusion with other buttons like the help one).
Moving the reset functionality as as icon-only + tooltip button into
the window header title bar was the proposal that had no real
disadvantage and solved the underlying UX issue by cleanly separating
submit from reset. Having reset near the close-window tool has no
negative implications, as both have a similar effect, the discard the
current pending changes that the user did not yet submit, so if one
mistakenly hits close instead of reset, or vice-versa, nothing is
lost.
A nice side-benefit of that option is that the change is really small
code wise.
Closes: #5277
Reported-by: Tristan Harward <trisweb@gmail.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Currently, `Proxmox.window.Edit` initializes `extraRequestParams` and
`submitOptions` to two objects that, if not overwritten, are shared
between all instances of subclasses. This bears the danger of
modifying the shared object in a subclass instead of overwriting it,
which affects all edit windows of the current session and can cause
hard-to-catch GUI bugs.
One such bug is the following: Currently, the `PVE.pool.AddStorage`
component inadvertently adds `poolid` to an `extraRequestParams`
object that is shared between all instances of `Proxmox.window.Edit`.
As a result, after adding a storage to a pool, opening any edit window
will send a GET request with a superfluous `poolid` parameter and
cause an error in the GUI:
> Parameter verification failed. (400)
> poolid: property is not defined in schema and the schema does not
> allow additional properties
This breaks all edit windows of the current session. A workaround is
to reload the current browser session.
To avoid this class of bugs in the future, implement a constructor
that makes copies of `extraRequestParams` and `submitOptions`. This
ensures that any subclass instance modifies only its own copies, and
modifications do not leak to other subclass instances.
Suggested-by: Stefan Sterz <s.sterz@proxmox.com>
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Tested-by: Stefan Sterz <s.sterz@proxmox>
sometimes it's necessary or handy to add custom options to the submit
api call (e.g. timeout). So just expose a `submitOptions` where users
of the edit window can put their custom options.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of only checking the validity of the advanced items when the
form validity changed as a whole, add a validity change listener to
each field in the advanced section.
This improves the behaviour such that every time an advanced field
gets invalid the items are show, not only when the form was valid
before.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-By: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Sometimes the reset button does not make sense and the isCreate option
does not fit as well because with it, the submit button will be enabled
right away instead of waiting for the form to be valid.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
For passing some default params which are passed along automatically
when calling load and doing the submit.
Useful in PBS, as there we often have the snapshot ID in multiple
parameters, not included in the request path, required for various
API call.
The params take low precendence, and are overwritten by values in
form fields with the same name for submit, or explicit params passed
to load calls
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Restricting the defaultFocus of the edit windows to only focusable fields
ensures that windows like "PVE -> Virtual Machine -> Manage HA", which
has a first field of xtype "displayfield", receive focus upon opening.
This allows those windows to be closed with the ESC key, which only
works when an element inside has focus.
In newer versions of ExtJS (>= 6.2.0) this filter could be reduced to
"field:canfocus" or maybe even ":canfocus".
