Question about updates of default fields that are used by adopter as references instead of instances

[evilaliv3]

@fpietrosanti i've a question i would like you analyze with me.

suppose the following scenario:

• time 0: we deliver some field templates
• time 1: various adopters start using them as they are
• time 2: we deliver a new version of such template

in order to not change the setup of the adopter possibly braking it we should evaluate what to do while updating the contexts in matter of the fields used as reference.

1. we can update supposing that if one adopter is using our template he trust our changes to the templates. (this is not always real; suppose an adopter (ANAC) that at time 0 design the fields with us that then become the default; that adopter won't have such an automatic update
2. we can clone the old field inside the context wherever there is a field used for reference that is changed; this seems a solution but has a great drawback: suppose a little change in "Whistelblower Identity" adding a specific question, duplicating all the field gerarchy would end in duplicating also the cities lists, the regions, the countries etc and we do not want this for sure.
3. we can ask too the user; but what? it will be difficult to communicate/show the user what is changed
4. a good possibility (i'm totally for this) we would need to not change auomatically the field templates making it a manual process (with an admin button) an making possible for the user that want the system to be automatically updated to mark "update fields automatically) [this may be also the default]; as fields are gerarchic and described by a json we are also able to checksum them and eventually field by field say to the user what is changed and make them accept or not the update. but this capability can be offered as second stage implementation.

what do you think?

[fpietrosanti]

I would definitely go for 1, extending the informative object referenced as template that we maintain as we need. If we change it, it will be changed automatically for the end-user.

To adjust behaviors (like having additional selectors for specific general use-cases), we must made it configurable (not customable), so it can have more or less fields, behave in a way or another one depending on the use case.

For example for Whistleblower Identity we already know that for uses by ANAC we'll need to have some specific additional fields and some specific behaviour, that shall be made configurable on the "Whistleblower Identity" feature.

We may also consider not to call that "templates" because they are "product features" with specific application logic and contextual configuration behaviors.

A template instead, is something "static" that you can use, copy, clone, customize.

A feature is something dynamic that you can enable, disable and configure.

Is we manage "Whistleblower Identity" as a feature, we can think at it differently than a template.

[evilaliv3]

Deprecated in favour of #2039