The confirmation dialogs of the following actions are affected by this
change:
* Remove
* Clone
* Migrate
* Snapshot
* Snapshot restore
* Backup VM/CT from config view
* Restore VM/CT from config view
A combination of VM/CT id and name is added to each confirmation dialog.
The order of id and name depends on the sort field selected in the tree
settings. If "Name" is selected, the confirmation dialogs will show "VM
name (VMID)". In any other case, "VMID (VM name)" will be used.
The VM/CT name is considered optional in all handled cases. If it is
undefined, only the VMID will be displayed in the dialog window. No
exceptions are thrown in case of an undefined guest name because it
only extends the information displayed to the user and is not essential
for performing any of the actions above.
Signed-off-by: Michael Köppl <m.koeppl@proxmox.com>
Some languages need to know about the argument here to allow for a
better translation (text order).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
instead of filtering pools and groups out manually, simply accumulate
the info we want to to have (status/hastate/etc.) and if any of those
exist, show the tooltip.
This results in the nodes also having a tooltip, including their hastate
(such as online/maintenance), and automatically would show such things
in the future if we add those fields to other entries.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of just using the filterfn directly, return a function from
`getFilterFn`. This way, when we want to filter different things
depending on e.g. local storage values, we don't have to do that for
every element, but only once and return the finished filterFn.
while at it, rename 'filterfn' to camel case 'filterFn'.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
when ordering items on the same level, we often sort first by type, but
do this via string comparison of the types.
this leads to weird results if we have e.g. lxc/node/qemu mixed in one
list, as nodes would sort in between lxc and qemu
this patch solves that issue by introducing a fixed order for types, so
we have direct control over the order when mixing types without having
to change the type names.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
and keep the functionality in ResourceTree as generic as possible.
We achieve this by having an 'itemMap' function that can split one item
from the store into multiple to add to the tree.
for the updates, we have to have an 'idMapFn' (to get the original id
back)
we also have to modify how the move checks work a bit, since we only
want to move the items when the tags changed only in the tagview case
in the ResourceGrid we have to get the id a bit differently since we now
have 'virtual' ids for the entries tag contain the tag (which can't be
found in the resource store)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Currently custom mappings cannot be edited, due to them having no VMID
value. The VMID parameter was always sent by the frontend to the
update call - even if it was empty - leading to validation failure on
the backend. Fix this by only sending the vmid parameter when it is
actually set.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
that function is not only there for the storage indicators, but
generally for adding additional information, such as tags, and for
wrapping in a span for making tooltip selection easier.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
When a node element was updated, it was put through the 'setText'
method which accidentally added a space before it's name.
Fix this by putting the space into the status variable.
Without this patch one could observe a vertical misalignment when some
nodes had guests on them but others had none.
Fixes: 2f414c50 ("ui: resource tree: limit tooltip to icon and text")
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The ip parameter has been added to the delete endpoint, so only a
specific mapping gets deleted instead of all mappings for that mac
address. Reflect this change in the UI.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
stop the tooltip show when the there is no text
this could happen for e.g. nodes that should not have a tooltip
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
it shouldn't be called that often, and if we save it, it gets outdated,
e.g. when starting/stopping a guest
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
and exclude the tags for that, since we want the tags to have their own
tooltips
we use the delegate function of the tooltips for that
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
by removing the confusing buttons in the toolbar and adding them as
actions in an actioncolumn. There a only relevant actions are visible
and get a more expressive tooltip
with this, we now differentiate between 4 modes of the edit window:
* create a new mapping altogether
- shows all fields
* edit existing mapping on top level
- show only 'global' fields (comment, mdev), so no mappings
* add new host mapping
- shows nodeselector, mapping (and mdev, but disabled)
(informational only)
* edit existing host mapping
- show selected node (displayfield) mdev and mappings, but only
mappings are editable
we have to split the nodeselector into two fields, since the disabling
cbind does not pass through to the editconfig (and thus makes the form
invalid if we try that)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by changing into 'mapping matches host data' which indicates that the
configured values matches the host information
also for the pci and usb map selectors
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this will be the base class for trees for the individual mapping types,
e.g. pci and usb mapping.
there are a few things to configure, but the overall code sharing is
still significant, and should work out fine for future mapping types
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if the user has the tree sorted by name, we have to move the items
on a name change, otherwise they'll stay on the old position
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Considers the newly added options from browser local storage. We have to
save the last sorting mechanism there, so we can detect if it changes
and trigger the movement/text changes (otherwise the tree nodes won't
be updated/moved)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
a new singleton like Utils/Parser, intended for holding stuff for
ui options, such as the tag settings/overrides
no behavioural change intended
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
and update the treenodes when the tags change.
since we change the vm node text (which we pass through to the config
panel), we have to change how we generate the text there slightly
(otherwise that would include the rendered tags)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we sort templates at the end normally, but if we convert a guest to a
template, it was not moved in the tree
add it to the list of attributes that are checked for a move
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-By: Aaron Lauterer <a.lauterer@proxmox.com>
on extjs 7.0, this triggers when the handler is not available anymore,
so use the beforedestroy event instead
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
our gettext extractor cannot handle such statements to extract the
gettext, so change it to two gettexts
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
similar story than commit 9cc4958f5a
We cannot really assert anything about the state of me (the view) and
consorts if me.destroyed is true, just early return.
We can get here because this is a delayed task, i.e., async,
everything can happen in between triggering it and receiving the
actual callback, so guard!
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
If one switched through guest fast (e.g., keeping the down-arrow key
pressed) while staying on the snapshot panel, it could happen that
the previous view got already destroyed once the success callback of
the feature API request got executed.
Then the ExtJS ViewModels' set method got a "null" back from its
me.getStub(...) call, and tried to access members of that, resulting
in a TypeError exception.
Avoid that by checking if we're already destroyed or still around
before doing that call. During the time we are already in the
callback we shouldn't be able to get destroyed in parallel due to JS
single thread nature and no yield point here, so this is safe.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Use arrow functions to bring them in a more simple boolean expression
style. Further, we can reuse the "isSnapshot" formula in the
"canRollback" and "canRemove" ones.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
using the better View, ViewModel, Controller style,
while doing this, make it generic so that we can use it for qemu and lxc
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This was already proposed by Dominik[0], but it was was wished for a
faster backend backing of this[1], and as with most wishes one needs
to either be content with what's there or (try) to improve it one
self.. So with the IPCC approach proposed as backing for this I'd
like to add this again. It differs from [0] a bit, first it's rebased
as parts of the tooltip stuff got already applied[2].
I use "Config locked (<LOCK>)" as text for this, as it
1. Clarifies what the lock symbol means, which is always a good thing
for tooltips
2. repeating the lock symbol here again would show the users three
lock symbols at the same time if the VM was selected in the tree
(the tree one, the VM config panel one, and this tool tip one)
this is a bit much, so don't do it.
[0]: https://pve.proxmox.com/pipermail/pve-devel/2019-February/035829.html
[1]: https://pve.proxmox.com/pipermail/pve-devel/2019-March/035930.html
[2]: https://pve.proxmox.com/pipermail/pve-devel/2019-March/036165.html
Co-developed-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
