From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 0B5B01FF0AE for ; Tue, 13 Oct 2026 09:47:43 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id BEFDF2131E; Tue, 13 Oct 2026 09:47:41 +0200 (CEST) Message-ID: <69cf0afd-8045-4137-b8ef-fb32df7de841@proxmox.com> Date: Tue, 13 Oct 2026 09:47:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH manager v7 17/24] ui: guest ID selector: show the error returned by nextid To: =?UTF-8?Q?Michael_K=C3=B6ppl?= , pve-devel@lists.proxmox.com References: <20261005144805.825538-1-m.koeppl@proxmox.com> <20261005144805.825538-18-m.koeppl@proxmox.com> <8be4919b-c4d3-4a63-b175-da59efbb9de6@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791877651320 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.291 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: EOMTIZTFQYOGPEZ7YFM6T6UQXIUOU7L3 X-Message-ID-Hash: EOMTIZTFQYOGPEZ7YFM6T6UQXIUOU7L3 X-MailFrom: f.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 12.10.26 um 4:23 PM schrieb Michael Köppl: > On Fri Oct 9, 2026 at 6:22 PM CEST, Fiona Ebner wrote: >> Am 05.10.26 um 4:50 PM schrieb Michael Köppl: >>> The guest ID field validates IDs through the /cluster/nextid endpoint >>> and reported any failure, including failed requests, as the ID being >>> in use. Show the error the endpoint returns instead, so that the >>> actual reason for rejecting an ID is visible. This is also needed for >>> the endpoint to reject IDs that are not in use, but forbidden by the >>> next-id datacenter option. >>> >>> Signed-off-by: Michael Köppl >>> --- >>> www/manager6/form/GuestIDSelector.js | 8 +++++--- >>> 1 file changed, 5 insertions(+), 3 deletions(-) >>> >>> diff --git a/www/manager6/form/GuestIDSelector.js b/www/manager6/form/GuestIDSelector.js >>> index f3160a744..fdf9e7610 100644 >>> --- a/www/manager6/form/GuestIDSelector.js >>> +++ b/www/manager6/form/GuestIDSelector.js >>> @@ -27,7 +27,7 @@ Ext.define('PVE.form.GuestIDSelector', { >>> } >>> >>> if (me.validateExists === false && me.rejected) { >>> - return me.inUseID; >>> + return me.nextIDError; >>> } >>> >>> return true; >>> @@ -37,7 +37,6 @@ Ext.define('PVE.form.GuestIDSelector', { >>> var me = this; >>> var label = '{0} ID'; >>> var unknownID = gettext('This {0} ID does not exist'); >>> - var inUseID = gettext('This {0} ID is already in use'); >> >> Nit: it's a bit unfortunate that we lose this message with gettext(). >> Can we somehow distinguish this and the enforcement case and still show >> it if it's not the enforcement case? We do cache the guest list in the >> UI, so maybe checking that, without even needing to do a 'nextid' API >> call then? Could also be a follow-up, but would be nice for UX. > > Yeah true, it's not really worth losing the translation here. I think it > makes sense to always go through nextid, though. Because if we're > relying on the cached guest list, there could be cases where e.g. the > creation of a guest is blocked if the guest list hasn't been refreshed > since a guest was removed and we check against that cached list. Always > making the request here would be worth it IMO. > Ack, fair point!