Need proper Role that prevents user from changing Authorizer.
We need to have option to choose can user change authorizer or not. Currently the users can change authorizers what is a threat for Authorization flow. Using the role "Medius.Enterprise.AuthorizationKeys.TaskItems.NoAuthorizerChangesAllowed " for user prevents from changing the Authorization, but from the other hand removes the Authorizer at all, when something else is changed in the coding. Yes, user can fetch the Authorizer, but this does not guarantee that the same Authorizer is restored, as the Authorizer could have been changed or manually added in the Distribute phase (ie. is not fetched either originally).
So basically what we are looking for, is very simple solution: a role, that prevents user from changing the authorizer without any other side effects.
Additionl info / Support case #87116
Anryo Raamat
shared this idea
-
Anryo Raamat
commented
Thank you for the explanation.
Yes – it works exactly as you described and authorizer can be fetched “back” on the coding line if it have been changed. And here is the good and bad in this – it allows “fetching” the authorizer, instead of “not allowing to change” it, as the title of the rule says.
Anyway – I understand, that this is how the rule is setup – but we can’t use it, because not 100% all authorizers are fetched and on those cases it does not keep the original authorizer. -
I try to explain why it works in this way.
It's very common that GL account is connected with a budget owner. This means there's a very strictly relation between the coding and the approver.
Before introducing ''Medius.Enterprise.AuthorizationKeys.TaskItems.NoAuthorizerChangesAllowed'' approver was able to redistribute his coding line to any other approver with a bigger authorization limit. So the invoice could be authorized by approver’s friend with a proper limit. That was a security gap.
Another problem was the fact that approver could change the coding on his coding line and put his cost into the budget of other approver and kept his budget clear.
Thanks to the new access key we can prevent scenarios mentioned above. Authorizer field can’t be filled in manually. Additionally if coding was changed this filled is empty and approver can be added only by ‘’Fetch authorizer’’ button, which means that system finds approver automatically based on configuration e.g. provided coding.
