When the up or down arrow key on the keyboard was pressed while a
number text field (or any one descending from Ext.form.field.Spinner)
was selected, the up and down callbacks for that text fields KeyNav
were called twice. Therefore, the value in the text field would always
incorrectly increment/de
On 01.07.2022 16:21, Dominik Csapak wrote:
i can add the same isos multiple times. does that make sense?
i know i can use different target names for them, but what would
that be good for? imho preventing the user from uploading
the same iso multiple times would be good
Same iso meaning two files
while introducing a 'product' parameter to the relevant functions and
adding wrappers for backwards-compatibility.
Suggested-by: Wolfgang Bumiller
Signed-off-by: Fabian Ebner
---
Changes from v1:
* Add wrappers, so we can defer the Breaks to later.
* Drop unnecessary changes in Proxmox/
which is shared between PVE and PMG.
Signed-off-by: Fabian Ebner
---
No changes from v1.
(build-)dependency bumps for libproxmox-perl-rs needed.
src/PMG/API2/APT.pm | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/PMG/API2/APT.pm b/src/PMG/API2/APT.pm
index 18b
which is shared between PVE and PMG.
Signed-off-by: Fabian Ebner
---
No changes from v1.
(build-)dependency bumps for libproxmox-perl-rs needed.
PVE/API2/APT.pm | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/PVE/API2/APT.pm b/PVE/API2/APT.pm
index 9cf02e45..fbcd1
On 07/07/2022 10:21, Fabian Grünbichler wrote:
> if processing a corosync.conf update is delayed on a single node,
> reloading the config too early can have disastrous results (loss of
> token and HA fence). artifically delay the reload command by one second
> to allow update propagation in most sc
if processing a corosync.conf update is delayed on a single node,
reloading the config too early can have disastrous results (loss of
token and HA fence). artifically delay the reload command by one second
to allow update propagation in most scenarios until a proper solution
(e.g., using broadcasti
On 05/07/2022 10:52, Fabian Ebner wrote:
> It's not clear to users that the "VM data" includes mount point
> volumes including those that are not marked for backup. This is
> different from VM restore, where volumes attached at drives not
> present in the backup will be kept around as unused volume
Am 06.07.22 um 13:13 schrieb Wolfgang Bumiller:
> On Wed, Jul 06, 2022 at 10:54:17AM +0200, Fabian Ebner wrote:
>> while introducing a 'product' parameter to the relevant functions.
>>
>> Suggested-by: Wolfgang Bumiller
>> Signed-off-by: Fabian Ebner
>> ---
>>
>> I did the changes in Proxmox/Lib/
