IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Less lines exeeding the character limit, less nesting, less duplicate code,
more readable sprintf arguments.
Co-authored-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
especially on chromium based browser (e.g. chrome, edge) it can happen,
depending on the zoom level, that the last column does not fit next to
the other columns and is moved below the other columns.
This results in an ugly looking UI and in the worst case makes it
unusable.
This can also be triggered if the monitor is set to a higher scaling /
different DPI settings. I was able to have the same problem in Edge when
setting the scaling in the windows display settings to 125% (Clone VM).
Changing the layout from columns with 0.5 width to extjs HBOXes with
flex 1 works as expected.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Commit 5ba2a605ac14de58572f7b8d6e04b45b34724b0a hard-coded 0 as the default
for maxfiles in the --storage case, but the actual default should be the
value from read_vzdump_defaults(), which obtains the value from
/etc/vzdump.conf or the VZDump schema if the value has not been modified in
that file. The initial default from the schema is 1, not 0.
Tested on PVE 6.1 to verify that behavior.
Move the sanity check for zero-ness to where we have the final value for
maxfiles. Like this, we also have an implicit definedness check and more
importantly, it is more future-proof in case we ever allow maxfiles 0 in the
VZDump schema itself.
Also, force conversion to int to be extra safe.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The html/text part already has VMID NAME STATUS TIME..., but the text part only
had VMID STATUS TIME... so far. Therefore, add the missing "name" column.
Limit the length of names so that the content of the following columns remains
aligned to the headings. Note that (like before, too) this only works with
monospaced fonts.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
because different pools can have different crush rules, etc.
the sum of the 'percentage used' column makes no real sense, so we
remove it
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
So we have first backups, then disk images (VM, CT), then templates
(VM, CT) and finally snippets.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
else some panels try to use conetent view before it is defined,
triggering the ExtJS auto-load from server magic, which fails - while
it does not breaks the UI, it generates a warning in the console and
an unnecessary request doomed to fail anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
depending on the content type, we might want to show different information, e.g.
parent for cloned VM/CT images, verification for backups, etc. Of course the
properties would have to be added to the model and the availableColumns first
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The enableFn's that were responsible for switching
between the image remove button and the standard remove button
are not needed anymore.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Organized as separate "if"s to allow changing properties easily later.
The StorageContentView now serves as a parent class, so the stateId
cannot be fixed there. Instead make each individual view stateful with a
unique stateId.
statusStore is not needed anymore, now there is a single fixed content type,
and the template and upload button are disabled depending on that type.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
note that the key is really important, add our recommended backup
strategy (copy to PW manager, save onto secured USB drive, print
paperkey and secure it) with the respective buttons to do so.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this was partial copied over from PBS, but there we pull out the task
startime alreay when building the store.
As eslint mentions, task was unused, verify_time not defined, fix
that.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
verification column only shows in the backup grid and for
pbs storages
(renderer is mostly copied from proxmox-backup)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
If neither the 'remove' option of vzdump nor the 'maxfiles' option in
the storage config are set, assume a value of 0, i.e. do not delete
anything and allow unlimited backups.
Restores previous behaviour that was broken in 7ab7d6f15f.
Also fixes a warning about using '== 0' on a non-number type.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
If a guest's QEMU process is 'running', but QMP says 'shutdown' or
'prelaunch', the VM is ready to be booted anew, so we can show the
button.
The 'shutdown' button is intentionally not touched, as we always want to
give the user the ability to 'stop' a VM (and thus kill any potentially
leftover processes).
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
fixes commit 43ff41c6c58ea8f6c28ef0a4012b4af706fa280b, which changed
the logic to the newer storage prune helpers, but those are designed
in the spirits of PBS, with a keep-option not set meaning to keep
none.
This does not respects the storage special handling of maxfiles.
While in the API/CLI that option must be > 0m in can be zero when set
in a storage configuration entry, and then it means keep all. So, set
the internal remove option to false if that special condition is met.
This would have been a clearer, and less prone to changes,
implementation to begin with.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
since some users don't even have a full 1500 (and some systems might
have links with bigger MTU and not require as much fragmentation).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
