From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pve-devel] [PATCH access-control/manager v2] fix #3668: improving realm sync
Date: Wed, 23 Mar 2022 09:21:31 +0100 [thread overview]
Message-ID: <9ea78b7f-5d99-c9ab-2e3c-22bb01c35d61@proxmox.com> (raw)
In-Reply-To: <850588f1-aea9-d5fe-6419-c74ec655512d@proxmox.com>
On 23.03.22 08:33, Thomas Lamprecht wrote:
>>> remove-vanished: [<user>];[<properties>];[acls]
>>>
>>> I.e., those three flags would replace your new mode + purge like:
>>>
>>> +--------+--------+---------------------+
>>> | Mode | Purge | -> removed-vanished |
>>> +--------+--------+---------------------+
>>> | update | 0 | "" (none) |
>>> | sync | 0 | user |
>>> | full | 0 | user;properties |
>>> | update | 1 | acl |
>>> | sync | 1 | acl;user |
>>> | full | 1 | acl;user;properties |
>>> +--------+--------+---------------------+
>>>
>>> The selector for them could be either three check boxes on one line (similar to the
>>> privilege level radio buttons from CT restore) or even a full blown combobox with all
>>> the options spelled out.
>>>
>>> It's only slightly weird for acl, as there the "remove-vanished" somewhat implies that
>>> we import acl's in the first place, if we really don't want that we could keep
>>> "Purge ACLs" as separate option that is only enabled if "remove-vanished" "user" flag
>>> is set, put IMO not _that_ of a big problem to understand compared to the status quo.
>>>
>>> Does (any of) this make sense to you?
>> yes this sounds sensible, but i agree about the possibly confusing 'remove-vanished'
>> implication for acls. Maybe 'remove-on-vanish' ?
> sounds the same to me semantically, so see no improvement there.
>
>> this would (semantically) decouple the 'vanished' thing from the 'removed' thing,
>> at least a little bit.
> IMO purely subjective and if a real grammar/semantic connection would be there that
> I just miss (always a possibility) it'd be to subtle.
>
> I think that the confusion potential overall would get quite a bit reduced that getting
> this slightly confusing one newly is still a net benefit and can be easily defused with
> a short docs note.
>
FWIW, for a user interface we can also go for a more detailed, telling approach, e.g.,
with both, field and box labels:
Remove Vanished:
Users [ ] Remove any realm-user not included in the sync response.
ACLs [ ] Remove the ACLs of any realm-user not included in the sync response.
Properties [ ] Remove properties not included in the sync response.
(more concise sentences welcome ;-))
For properties we could add a " Note: breaks, among other things, TFA." hint as
tooltip or just in the docs.
prev parent reply other threads:[~2022-03-23 8:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-04 14:24 Dominik Csapak
2022-02-04 14:24 ` [pve-devel] [PATCH access-control v2 1/2] realm-sync: replace 'full' option with 'mode' Dominik Csapak
2022-02-04 14:25 ` [pve-devel] [PATCH access-control v2 2/2] fix #3668: realm-sync: add mode 'sync' Dominik Csapak
2022-02-04 14:25 ` [pve-devel] [PATCH manager v2 1/1] ui: realm sync: replace 'full' with 'mode' Dominik Csapak
2022-03-22 6:11 ` [pve-devel] [PATCH access-control/manager v2] fix #3668: improving realm sync Thomas Lamprecht
2022-03-22 13:44 ` Thomas Lamprecht
2022-03-22 15:23 ` Dominik Csapak
2022-03-23 7:33 ` Thomas Lamprecht
2022-03-23 8:21 ` Thomas Lamprecht [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=9ea78b7f-5d99-c9ab-2e3c-22bb01c35d61@proxmox.com \
--to=t.lamprecht@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