From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <t.lamprecht@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 567C2692DC
 for <pve-devel@lists.proxmox.com>; Wed, 23 Mar 2022 09:22:05 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 4D76E24801
 for <pve-devel@lists.proxmox.com>; Wed, 23 Mar 2022 09:21:35 +0100 (CET)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS id B4F26247F7
 for <pve-devel@lists.proxmox.com>; Wed, 23 Mar 2022 09:21:34 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 8811346F6A
 for <pve-devel@lists.proxmox.com>; Wed, 23 Mar 2022 09:21:34 +0100 (CET)
Message-ID: <9ea78b7f-5d99-c9ab-2e3c-22bb01c35d61@proxmox.com>
Date: Wed, 23 Mar 2022 09:21:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:99.0) Gecko/20100101
 Thunderbird/99.0
Content-Language: en-US
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
 Dominik Csapak <d.csapak@proxmox.com>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20220204142501.1461441-1-d.csapak@proxmox.com>
 <d2fa2293-72d8-e9c8-96e6-b85664557f93@proxmox.com>
 <50f39747-1685-92d4-ae3e-5cfe5c288776@proxmox.com>
 <a33d85c1-158a-55e3-e920-55a3ff44d50c@proxmox.com>
 <850588f1-aea9-d5fe-6419-c74ec655512d@proxmox.com>
In-Reply-To: <850588f1-aea9-d5fe-6419-c74ec655512d@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.056 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -0.001 Looks like a legit reply (A)
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
 T_SCC_BODY_TEXT_LINE    -0.01 -
Subject: Re: [pve-devel] [PATCH access-control/manager v2] fix #3668:
 improving realm sync
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Wed, 23 Mar 2022 08:22:05 -0000

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:
>>>
>>> +--------+--------+---------------------+
>>> |=C2=A0 Mode=C2=A0 | Purge=C2=A0 | -> removed-vanished |
>>> +--------+--------+---------------------+
>>> | update |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 | "" (none)=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
>>> | sync=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 | user=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |
>>> | full=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 | user;propertie=
s=C2=A0=C2=A0=C2=A0=C2=A0 |
>>> | update |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 | acl=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 |
>>> | sync=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 | acl;user=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
>>> | full=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 | acl;user;prope=
rties |
>>> +--------+--------+---------------------+
>>>
>>> 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 c=
ombobox with all
>>> the options spelled out.
>>>
>>> It's only slightly weird for acl, as there the "remove-vanished" some=
what implies that
>>> we import acl's in the first place, if we really don't want that we c=
ould keep
>>> "Purge ACLs" as separate option that is only enabled if "remove-vanis=
hed" "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 're=
move-vanished'
>> implication for acls. Maybe 'remove-on-vanish' ?
> sounds the same to me semantically, so see no improvement there.
>=20
>> this would (semantically) decouple the 'vanished' thing from the 'remo=
ved' thing,
>> at least a little bit.
> IMO purely subjective and if a real grammar/semantic connection would b=
e there that
> I just miss (always a possibility) it'd be to subtle.
>=20
> I think that the confusion potential overall would get quite a bit redu=
ced that getting
> this slightly confusing one newly is still a net benefit and can be eas=
ily defused with
> a short docs note.
>=20


FWIW, for a user interface we can also go for a more detailed, telling ap=
proach, 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." h=
int as
tooltip or just in the docs.