Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autofilled parameter values #216

Open
1 task
FRosner opened this issue Jun 4, 2017 · 0 comments
Open
1 task

Autofilled parameter values #216

FRosner opened this issue Jun 4, 2017 · 0 comments
Milestone

Comments

@FRosner
Copy link
Owner

FRosner commented Jun 4, 2017

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

  • 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*)?
@FRosner FRosner added this to the 0.7.0 milestone Jun 4, 2017
@FRosner FRosner mentioned this issue Jun 4, 2017
3 tasks
@FRosner FRosner modified the milestones: 0.7.0, 0.8.0 Aug 14, 2017
@FRosner FRosner modified the milestones: 0.8.0, 0.9.0 Mar 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant