Create change on behalf of initiator

[BobSilent]

Provide possibility to apply aggregator changes on behalf of event initiator.

The provided PAT needs to have the appropriate permission to bypass rule validation.

the configuration can be made either

• in rule code via directive for every mapping or
• during map.rule command for a dedicated invocation.

Provides solution for #62

[giuliov]

I will look at this more deeply, but I am surprised at the mixed design. Impersonation is a mapping property or a rule property?

Looks like you can have more than one mapping to the same rule, some with some without, the impersonate flag. One can set the flag at rule level using a directive and this latter wins over the mapping. On the other hand the add.rule has no option to set this flag.
I would summarize: it is a property at both levels and rule-level wins.

I would opt for a property defined at rule-level: one can upload the same source twice to create two rules, one with, the other without impersonation.

A stretch goal would be to highlight the impersonation configuration in list.rules output. This is easy if, instead of a directive, you put this flag in the rule configuration (i.e. the application settings). It also enables adding the flag on the add.rule command.

[BobSilent]

I will look at this more deeply, but I am surprised at the mixed design. Impersonation is a mapping property or a rule property?

you are right, it came during development and thats why I wanted to show the code early to start the discussion here with you about the solution direction. 😃

Looks like you can have more than one mapping to the same rule, some with some without, the impersonate flag. One can set the flag at rule level using a directive and this latter wins over the mapping. On the other hand the add.rule has no option to set this flag.
I would summarize: it is a property at both levels and rule-level wins.

Yes, that is currently.
I started with the Idea to decide it when mapping the rule, because then I know the identity permission for the rule instance and I know that I want impersonation for a rule. Therefore I implemented it for map.rule, to decide per mapping (i have multiple mappings to same rule from different projects - yes larger organization).

Afterwards I faced the situation for one rule: This rule should always run impersonated (on behalf of the event trigger identity).
First Idea was to add it during add.rule, but then I need to know it everytime when adding the rule to an instance. For development I have the rules in source control, and it is also not always me who writes or adapts or deploys a rule.

So it made sense to me to have the information in rule code (directive) as well, to show it everyone looking at the rule code: This rule is an (always) impersonated one.

To summarize, in current code you can decide per mapping if rule should be executed impersonated, or it is in general decided in rule code (which always wins).

I would opt for a property defined at rule-level: one can upload the same source twice to create two rules, one with, the other without impersonation.

This would either be an additional Option or as replacement for the rule directive.
If we go this way, i would loose the information in my rule code and move it to my "release stage" where i do the rollout of rule files.

A stretch goal would be to highlight the impersonation configuration in list.rules output. This is easy if, instead of a directive, you put this flag in the rule configuration (i.e. the application settings). It also enables adding the flag on the add.rule command.

Yes, I am not finished, I also wanted to show this information in the lists commands (either list.rules or list.mappings or both - depending on solution)

What do you think?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[giuliov]

Merged in 84212cb and 4d4a0eb.