Forum Discussion

ogonzalez's avatar
ogonzalez
New Contributor II
2 months ago
Solved

Run a DM as a different user

Hi there,

We have one Business Rule that reorganize some security groups adding/removing Parent Groups based on a certain hierarchy, however, we are facing the issue that when the user executing this Business Rule belongs to a group that is being reorganized, we get the following error message:

"Security Access Error. You cannot add/remove yourself or a group that you belong to or an Administrators group to/from the current group."

That error is perfectly reasonable, but we need to find a way to bypass that.

In other softwares exists the possibility to execute a Job as a different user (usually non-interactive) which has the required security configuration to ensure the process is executed successfully.

How can we achive that same result in OneStream?

Thank you!

Bests,

  • DanielWillis's avatar
    DanielWillis
    2 months ago

    I think this is usually solved by changing the process a little. Instead of a user clicking a button to execute the job, the user clicks a button that records somewhere (e.g., some sort of queue) that the user wants to execute the job. A scheduled task with appropriate privileges is configured to run frequently which checks the queue to see if there is anything that needs to be and should be run, and then runs it.

2 Replies

  • DanielWillis's avatar
    DanielWillis
    Valued Contributor
    2 months ago

    I think this is usually solved by changing the process a little. Instead of a user clicking a button to execute the job, the user clicks a button that records somewhere (e.g., some sort of queue) that the user wants to execute the job. A scheduled task with appropriate privileges is configured to run frequently which checks the queue to see if there is anything that needs to be and should be run, and then runs it.

  • MarcusH's avatar
    MarcusH
    Valued Contributor
    2 months ago

    If you are not an Administrator, you cannot change any security groups that you are assigned to. The way round this is to have separate distinct groups assigned to all the Application and Security Roles and pages (let's say they start with AR, AP, SR and SP). By that I mean a security group for these functions is only assigned once. Then you have other security groups that inherit these AR, AP, SR and SP groups (lets call them UserRole groups). The user who is executing the BR has his/her own set of UserRole groups ie no one else has access to them. The standard users have a different set of UserRole groups. This should allow the executing user access to manage the groups without changing his/her own security. As far as I know, you cannot execute a BR using a different user.