all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] ui: resource mappings: fix editing of mapping for non first node
Date: Wed, 24 Jul 2024 11:44:39 +0200	[thread overview]
Message-ID: <2933183f-8da4-42c6-9dbb-f7a20cd3d295@proxmox.com> (raw)
In-Reply-To: <20240426071724.1126646-1-d.csapak@proxmox.com>

Am 26.04.24 um 09:17 schrieb Dominik Csapak:
> when editing the pci mapping, we set the nodename of the pciselector
> to the selected node. At the same time we disable and hide the node
> selector, but it still changes it's value to the 'first' node
> (alphabetically sorted) and that triggers a change event.
> 

It's the first node that's not in the disallowedNodes AFAICT.

> To prevent that we accidentally set the node of the pciselector
> too, we need to check here if the field is disabled.
> 

I wondered why the USB mappings don't suffer the same issue though. The
nodeChange() callback gets called with the correct value when editing
the mapping for a specific node, even though the node selector
definition and setting of disallowedNodes is the same as for the PCI
mappings.

Looking at Javascript backtraces, it seems like there might be some kind
of race going on (whether the me.getStore().load() for
PVE.form.NodeSelector finishes early or not), but not clue why it
happens for one, but not the other.

That said, adding a similar condition for the USB mappings would still
be good IMHO.

> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>

Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>

> ---
>  www/manager6/window/PCIMapEdit.js | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/www/manager6/window/PCIMapEdit.js b/www/manager6/window/PCIMapEdit.js
> index d43f04eb..faf58255 100644
> --- a/www/manager6/window/PCIMapEdit.js
> +++ b/www/manager6/window/PCIMapEdit.js
> @@ -126,8 +126,10 @@ Ext.define('PVE.window.PCIMapEditWindow', {
>  	    this.lookup('pciselector').setMdev(value);
>  	},
>  
> -	nodeChange: function(_field, value) {
> -	    this.lookup('pciselector').setNodename(value);
> +	nodeChange: function(field, value) {
> +	    if (!field.isDisabled()) {
> +		this.lookup('pciselector').setNodename(value);
> +	    }
>  	},
>  
>  	pciChange: function(_field, value) {


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  reply	other threads:[~2024-07-24  9:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-26  7:17 Dominik Csapak
2024-07-24  9:44 ` Fiona Ebner [this message]
2024-07-26  8:06 ` Dominik Csapak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2933183f-8da4-42c6-9dbb-f7a20cd3d295@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal