From: Stefan Hanreich <s.hanreich@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [PATCH pve-manager v2] fix #7300: acl path include pre-generated zones and fabrics
Date: Thu, 12 Mar 2026 14:55:45 +0100 [thread overview]
Message-ID: <23b2f4d7-01f5-4143-b0e4-569d8809888b@proxmox.com> (raw)
In-Reply-To: <20260311094220.36579-1-d.riley@proxmox.com>
Thanks for looking into this!
Tested this patch series on my machine and works as advertised -
comments inline.
On 3/11/26 10:42 AM, David Riley wrote:
> Permission Path selection will show:
> '/sdn/zones/<zone>'
> '/sdn/fabrics/<fabric>'
>
> The case 'network' is used because this will act as the top-level
> resource for all networking entities (including SDN).
>
> see: https://git.proxmox.com/?p=pve-manager.git;a=commit;h=9ac04d9572a458aeb891feb9b695d793cf7b122d
> Signed-off-by: David Riley <d.riley@proxmox.com>
> ---
When sending a new version of a patch series it is good to include a
changelog for the patch series. This makes life easier for people
reviewing the patch series and allows for easily seeing what changed.
Even if nothing really changed (afaict the Signed-off-by tag was missing
and has been added) it makes it easy to tell that nothing significant
changed from v1 ;)
> www/manager6/data/PermPathStore.js | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/www/manager6/data/PermPathStore.js b/www/manager6/data/PermPathStore.js
> index c7ec4231..bba7c7e7 100644
> --- a/www/manager6/data/PermPathStore.js
> +++ b/www/manager6/data/PermPathStore.js
> @@ -22,7 +22,7 @@ Ext.define('PVE.data.PermPathStore', {
> ],
>
> constructor: function (config) {
> - var me = this;
> + let me = this;
nit: this is not strictly related to the change and it might be better
to send as an upfront / separate patch.
>
> config = config || {};
>
> @@ -36,6 +36,9 @@ Ext.define('PVE.data.PermPathStore', {
> case 'node':
> path = '/nodes/' + record.get('text');
> break;
> + case 'network':
> + path = '/sdn/' + record.data['network-type'] + 's/' + record.data.network;
nit: the surrounding code utilizes .get() - so it'd make sense to do the
same here for the sake of consistency.
Unless there is a specific reason for accessing record.data directly?
> + break;
> case 'qemu':
> path = '/vms/' + record.get('vmid');
> break;
prev parent reply other threads:[~2026-03-12 13:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 9:42 David Riley
2026-03-12 13:55 ` Stefan Hanreich [this message]
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=23b2f4d7-01f5-4143-b0e4-569d8809888b@proxmox.com \
--to=s.hanreich@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox