After the UI hang for tens of seconds for a few thousand elements got
deselected I investigated with Firefox developer tools performance
analysis, where the waterfall view showed that most of the time was
spent in array splicing.
Previously, all removed elements got removed on by one from the
`selected` Ext.util.Collection - which is basically an helper class
around arrays and objects, most of it may have become obsolete with
modern browsers. The single remove resulted into further splicing of
the array, and all in all it resulted in a dramatically increased
complexity, ~ O(n^3).
The "remove one by one" logic comes highly probably from the fact
that users can register a `beforedeselection` listener which can
block a removal of a specific record. But, that's not used by us and
not really something one would often need in practice, but still its
a documented feature of ExtJS grids we want to keep; so go for an
alternative.
So, override `doDeselect` and change the old removal logic to one
that first record those entries which got blocked from removal and
remove them in one go from the "to-be-removed" collection.
Before/After this patch on my FF 86.0.1 with my i9-9900K and
deselecting ~10k records went from ~40s to about 33 ms total, so for
that case we went 1000x faster.
The remaining time is now mostly spend in the event fire/handling
logic, but even with 50k records we spent <<500ms in total, so not
too bad and thus kept as is for now.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reviewed-By: Dominik Csapak <d.csapak@proxmox.com>
Tested-By: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-By: Stoiko Ivanov <s.ivanov@proxmox.com>
Same deal, however, here the PVE code is has a little bug
where changing the plugin type of a domain makes it
disappear, so this also contains some fixups.
Additionally, this now also adds the ability to change a
domain's "usage" (smtp, api or both), so similar to the
uploadButtons info in the Certificates panel, we now have a
domainUsages info. If it is set, the edit window will show a
multiselect combobox, and the panel will show a usage
column.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Like with the account panel, the 'acmeUrl' base needs to be
specified, otherwise this is copied from PVE
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Copied from PVE with URLs now being based on the 'acmeUrl'
property which should point to the acme/ root containing
/tos, /directories, etc.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Again, initially copied from PVE but adapted so it can be
used by both. (PVE side still needs to be tested though.)
The 'nodename' property is optional (since on PMG we
currently don't expose them via the UI directly). Instead,
the certificate info URL is required and the 'uploadButtons'
need to be passed, which just contains the certificate
"name", id (filename), url, and whether it is deletable and
whether a GUI reload is required after changing it. If only
1 entry is passed, the button stays a regular button (that
way PVE should still look the same), whereas in PMG we have
a menu to select between API and SMTP certificates.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Mostly copied from PVE, but the user needs to set the URL
property so their stores can load the data, whereas in PVE
this was hardcoded.
API selector:
needs its url to point to the challenge-schema url
Acme Account selector:
needs its url to point to the acme account index
Acme Plugin selector:
needs its url to point to the plugin index
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We never use that and it serves no purpose. It probably was meant to
be the upstream config 'storeId' which would add the store to the
Ext.StoreManager. This is unpractical though, since then the store
has to be explicitely destroyed, otherwise the StoreManager retains a
reference and the GC cannot remove the store.
Since donwstream users of the store can simply give the 'storeId'
property anyway if they need to be managed by the StoreManager, drop
the requirement here.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
500 px still fit nicely in our minimum requirements of "HD ready"
(1280 x 720 px) and for any slightly longer running task the extra
pixel are really nice, I frequently find myself resizing the height
immediately after a task window opens so lets up the default a bit...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Using find_next_iface_id we get a valid VLAN name.
This way, inserting a vlan raw device is still required (but everything that is
inserted so far is valid).
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
We usually choose default values that are valid input for the field.
interfaceX.1 is rejected by the API.
Instead, use a tooltip to demonstrate possible valid inputs for the field.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
Users certainly have to insert a vlan raw device when the textfield is enabled.
Currently, they only see `invalid network interface name "` when submitting.
Forbidding the blank field shows the problem earlier.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
The regex are are created as literals (with // and not new RegExp).
Therefore
- The old Vlan_match value with double \\ has matched e.g. vlan\ddd instead
of e.g. vlan123 and
- the old VlanInterface_match value with double \\ has matched e.g.
\www\X\dddd instead of e.g. vmbr0.1234
This fixes automatically disabling the fields vlan-raw-device and vlan-id (VLAN
tag) in the VLAN edit window.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
Assigning the store directly to the treepanel doesn't work, more manual
handling is needed. This is mostly based on what we do for PBS's datastore
content view. The store monitoring also needs to be changed slightly.
The buttons are restricted to work on disks only, based on the parent
attribute, that only partitions have.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The drawing makes clear in a few seconds:
- what columnT and columnB stand for
- what additional containers and panels are created
- to which of those the elements of column1, column2... go to
When you're in the JS debugger and lost overview of where in this
element hierarchy you are, you can quickly check xtype + layout. Then
consulting this drawing solves the mistery.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
findRecord does not match exactly, but only at the beginning and
case insensitive, by default. Change all calls to be case sensiti
and an exactmatch (we never want the default behaviour afaics).
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
previously we printed this ceph info, but it got lost during
refactoring to widget-toolkit, restore a slightly modified
version of the code
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
there may be cases where the backend serialization plumping code
makes it easier to return null instead of a emtpy object if a
(sub)property or whole config is not configured, as it's closer to
the truth (not configured == null, configured but empty would be {})
For objects this resulted in a exception, as the null value was tried
to be dereferenced, avoid that by defaulting to an empty object in
that case.
For arrays we already coped with that by luck, make that more
explicit to avoid future breakage.
Both result to a empty array being returned as values, which means
empty store and is deemed to be OK in that case.
The rowdef.required still applies and adds empty values though, this
could be argued to not be really fitting - for now lets keep it that
way, we could make this opt-in though if it shows that it is not
always correct.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The corresponding option in /etc/network/interfaces is exactly "bond-primary".
Translating this might easily make unclear what is meant.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
mirrors columnB (column bottom) but is placed on the top, i.e.,
columnT.
One can no conveniently set the following layout:
+-------------------------------------+
| |
| columnT |
| |
+------------------+------------------+
| | |
| | |
| column1 | column2 |
| | |
| | |
+------------------+------------------+
| |
| columnB |
| |
+-------------------------------------+
(4 columns should work too, but we do not use that anywhere FWICT)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
allow that any of the three column/docked definitions can be set,
without setting the first one to an empty array to go in that if
branch.
Note, column2 works fine, but I did not greatly test a sole
advancedColumnB definition, so there may be still some improvements
for fixes - but at that point the user could also use advancedItems
to have full control.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
`useFieldContainer` doesn't seem to be used anymore in any of our
products:
* PVE
* PMG
* PBS
it therefore can be considered dead code.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
When scaling the browsers content either via the browser itself or
because the OS has a different scaling / DPI setting, it can happen that
not all columns have enough space next to each other and thus the last
column is moved further below.
This happens especially on chromium bases browsers (e.g. chrome, edge).
Changing the layout to use extjs HBOXes with flex instead of columns
solves works well.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
