but rather multiple times becoming exponentially less frequent.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
with the recent rework of the render/maps/arrays, we now
show 'Default (__default__)'. Since '__default__' is only an internal
value in the gui, don't expose it by explicitely checking for it
in the other render functions it works already because we either construct
the text differently (console_map) or we check the result from
parsing (vga_driver)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Use fieldsets, which are just way nicer for grouping these things.
Disable the "remove properties" checkbox if we'd remove the whole
user anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
in default sync options and the sync window. We do this by exposing
the individual flags as checkboxes. We get the mapped value from the
backend so we do not have to handle 'old' values here.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Became unused with commit 2bb03197d3
that moved the locale stuff to its own repo proxmox-i18n
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the 'value' here is already the rendered text, passing it through
render again does not make sense
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
to avoid a "malformed JSON string" warning when there is no old
version present (e.g. after starting a cluster).
get_node_kv will always return something that evaluates to true, so
instead, test if the result has an entry for the current node. Also,
it's enough to request the kv for the current node only.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
we prompt for confirmation in that case anyway, but some subtle, but
extra difference may still help
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For example, relevant if the filterVMID checkbox got turned off. But
a user may also want to make the restored VM unique in other cases
too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
For future or external storages where the assumption "multiple formats implies
qcow2 is supported" doesn't hold.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The backend will pick an appropriate format when nothing is specified. The
comment made it sound like 'raw' would be sent, but that didn't actually happen
on file-based storages, and now no format is sent, so adapt the comment too.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
this removes the NotesView panel and NotesEdit and replaces them with
with the version from the widget kit. requires a bump of the widget
toolkit.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
The form is basically a 1:1 copy from what the edit window gives us
for free already anyway, so just drop it.
best viewed with `git show -w`
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Double negated properties make it harder than necessary to parse
conditions.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Reviewed-by: Fabian Ebner <f.ebner@proxmox.com>
For the new HDReassign component, we follow the approach of HDMove to
have one componend for qemu and lxc.
To avoid button clutter, a new "Disk/Volume action" button is
introduced. It holds the Move, Reassign and Resize buttons in a
sub-menu.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reviewed-by: Fabian Ebner <f.ebner@proxmox.com>
Using the actual config key instead of the pluralization, makes it
easier in the situations where we need to match against it.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Reviewed-by: Fabian Ebner <f.ebner@proxmox.com>
Commit 809f6b6e ("ui: lxc resources: switch to vector based font
awesome icons") seems like an innocent change, but it broke the
(very brittle) logic here by removing the tdCls for rootfs.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
else this single call site is subtly different from all the rest, which
could cause problems further down the line if we ever change the prune
logic.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
since they are the ones relevant for pruning and protected backups
have their own separate limit.
Since get_backup_file_list is only used in places where the
unprotected backups are needed, adapt the helper accordingly.
If there is a storage, use PVE::Storage::volume_list to count the
unprotected backups. This avoids a direct invocation of the
proxmox-backup-client for PBS and the limit check can also work for
external storage plugins which might not be dir-based or name the
backups differently.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
on create we require either starttime (+dow) or a schedule, but when
updating an existing job, this is not necessary
before we changed to schedules, the starttime was not optional either on
update, but i think there is no reason to require the user to send the
schedule/startime along every time.
the gui will send all values every time, so that was never a problem there
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
We support external storage plugins, e.g., for proprietary
technology, so a "unknown" value here may not actually mean that we
missed anything, so just return the type value 1:1 as fallback, that
gives the user a better idea about such a storage entry.
Reported-by: Joshua Huber <jhuber@blockbridge.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
if we have a schedule that has no 'next event' we should skip the scheduling
instead of schedule every round
this can happen if someone sets an schedule that has no next match.
some examples:
* 2-31 00:00 (there is not February 31st)
* mon 2022-04-02 (this would be a saturday, not monday)
* 1970-1-1 (or every other exact date in the past)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
In preparation to have check_volume_access() always allow access for
users with Datastore.Allocate privilege. As to not automatically give
all such users permission to extract the config too.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
