You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases it is already clear or predetermined how parameter values need to be filled. This can be based on external factors such as current date, the username of the logged in user, etc.
Solution
We introduce static template parameters (need to be different from non-static, maybe starting with _). There is a predefined set of such parameters and they will not trigger a user input on the UI.
Variation 1
The static parameters are defined at compile time and can only be used in the template (e.g. current user, role, date, etc.)
Variation 2
There are two types of static parameters: Predefined and ad-hoc ones. Ad-hoc static parameters are defined in the meta.json and can be composed out of other parameters (e.g. predefined static or dynamic parameters).
Possible Problem: How deep should be allow to go? How do we avoid circular dependencies?
Variation 3
Shall we give permissions to overwrite the parameters inserted directly in the template (so ad-hoc or predefined ones used in template.json? I.e. that a admin can change the user name. I think for this we need a more granular permission scheme (#188) so maybe we can do it in a follow-up ticket.
Variation 4
We allow authority based predefined parameter values (e.g. {{_customer}}) which can be defined on a user or group level. E.g. we can say that all users belonging to customer A will have autofilled the {{_customer}} parameter. This requires adding a dictionary in the application.conf part used for defining accounts etc.
Questions
If we introduce multiple types of autofill parameters, how do we avoid naming collisions (e.g. we predefine the {{_user}} parameter but then someone puts a dynamic parameter called {{user}} in meta.json or application.json for a specific account? Should we separate them based on prefix and enforce the prefix on validation of the information? What are good prefixes? Different symbols (_, *, ^) or a combination out of the same symbol but different characters (*adhoc*, *predefined*)?
The text was updated successfully, but these errors were encountered:
Problem
In some cases it is already clear or predetermined how parameter values need to be filled. This can be based on external factors such as current date, the username of the logged in user, etc.
Solution
We introduce static template parameters (need to be different from non-static, maybe starting with
_
). There is a predefined set of such parameters and they will not trigger a user input on the UI.Variation 1
The static parameters are defined at compile time and can only be used in the template (e.g. current user, role, date, etc.)
Variation 2
There are two types of static parameters: Predefined and ad-hoc ones. Ad-hoc static parameters are defined in the
meta.json
and can be composed out of other parameters (e.g. predefined static or dynamic parameters).Possible Problem: How deep should be allow to go? How do we avoid circular dependencies?
Variation 3
Shall we give permissions to overwrite the parameters inserted directly in the template (so ad-hoc or predefined ones used in
template.json
? I.e. that a admin can change the user name. I think for this we need a more granular permission scheme (#188) so maybe we can do it in a follow-up ticket.Variation 4
We allow authority based predefined parameter values (e.g. {{_customer}}) which can be defined on a user or group level. E.g. we can say that all users belonging to customer A will have autofilled the {{_customer}} parameter. This requires adding a dictionary in the
application.conf
part used for defining accounts etc.Questions
{{_user}}
parameter but then someone puts a dynamic parameter called{{user}}
inmeta.json
orapplication.json
for a specific account? Should we separate them based on prefix and enforce the prefix on validation of the information? What are good prefixes? Different symbols (_
,*
,^
) or a combination out of the same symbol but different characters (*adhoc*
,*predefined*
)?The text was updated successfully, but these errors were encountered: