Yes, once the administrator has modified the value for that single
attribute the entire value for that attribute should be transferred over -
the tooling should not be attempting to merge two attribute values into one.
On Tue, 27 Mar 2018 at 18:49 Alexey Loubyansky <alexey.loubyansky(a)redhat.com>
wrote:
On Tue, Mar 27, 2018 at 6:01 PM, Darran Lofthouse <
darran.lofthouse(a)redhat.com> wrote:
> I think this takes us all back to the start.
>
> Why do you need to be modifying the simple-permission-mapper resource.
>
Because users will probably need to. Two use-cases.
1) I don't want to install the default distribution with its configs and
then start customizing it (given the complexity, in general, that is not a
trivial and safe exercise especially if you are doing it manually). I want
to install the already customized version (which is validated by the tool).
Hopefully, I won't need to modify the simple-permission-mapper but what if
I do want to?
2) I have my customized installation, there is a new compatible version
available. I want to upgrade but don't want to do the config-customizing
exercise again, i.e. i want my existing customizations to be preserved
after the update. For that the tool needs to be able to identify my
customizations that can be (re-)applied to the new version (assuming it is
a compatible release). Now if I added a permission-set to one of the
permission-mappings in the previous version, the tool won't be able to do a
fine-grained diff that can be re-applied.
The answer to both, and this is what you imply by saying that once an
administrator touched it it shouldn't be changed by anything else, this
part of the config is an atomic unit which has to be configured in its
entirety whenever you want any change in it.
Alexey