Re: LoginAdminWhitelist - do we need amendment support like we have for service users?

[Julian Sedding <js...@gmail.com>]

Hi all

I have created SLING-6357 to track this enhancement. I'll quote my
proposed solution from the issue description. Feel free to
comment/agree/disagree etc.

"""
I propose to remove the {{whitelist.bundles.default}} and
{{whitelist.bundles.additional}} properties and replace them by
"additional configurations" that each allow to provide a list of
whitlisted bundle symbolic names.

In the main configuration for {{LoginAdminWhitelist}} I propose to
retain the flag to bypass the whitelist completely.

I am uncertain, whether we really need the whitelist regexp for
testing, as it is fairly simple to list a hand full of required
bundles. If we keep it, I suggest to make its metatype private.

Optionally, we could consider the possibility to allow configuring a
list of required "additional configurations". I would leave this until
we find a real requirement for this, as it would complicate the
implementation.
"""

Regards
Julian


On Wed, Nov 30, 2016 at 1:10 PM, Stefan Seifert <ss...@pro-vision.de> wrote:
>
>>As I wrote, I see value in having the possibility to amend the
>>whitelist without losing entries managed by another entity.
>
> +1
>
> i see carstens point, but the pain in special environments like integration tests can quickly get bigger. currently it only works because we had luck that three different properties existed to define exclusions, and only two were already used in the launchpad.
>
> stefan
>