In capsule, how to restrict procedure launch for read only user ?

Julien CARDON

Hello,

In BOARD we have a P&L capsule shared between 2 user groups

• Controlling user that are allowed to launch procedure that may change data like clear data / reload data from ERP / launch allocation

• Reporting user that should only have read only access. They should not be able to launch procedure. The issue is that "Read only" access allow user to launch procedure

How are you managing such cases in your application ?

From my point of view it cannot be managed through native BOARD security layer ?

So we have use to use workaround :

• Are you using visiblity option on each button ?
• Are you putting "if condition" in your procedure as step 1 to exit the procedure if it's not an authorized user ?
• Other idea ?

Thanks for your feedback

Julien

Bettina Clausen

Hi,

I think you'd need to proceed with one of your mentioned workarounds.

I would suggest to proceed with including an if-condition into the procedure.
Why? Because in that case you can make sure that each time the procedure is being called, the restriction will be checked. If you have multiple screens/buttons with that procedure you are likely to forget at least one object. Additionally, I would assign permission to the functionality (so cube = 1 if access is granted) instead of flagging people who should not have access. In case the cube would be empty (maybe cleared by accident), you would prevent running the procedure at all instead of granting full access to it.

Kind regards,
Bettina

Marius Lubbe

Hi @Bettina Clausen,

I have a follow up question on the procedure menioned above.

We are looking to only give users access to run a specific procedure from a button if they have been granted permissino to do so.

How can we see the @User in the procedure or visibility, and how can we bring that @user into a table to give them access to the procedure or not?

We tried pulling in the user list following the processes from the Audit logs, but the problem is that the @User is not being compared to that entity.

So currently all of our users can click on buttons that would kick of procedures.

Bettina Clausen

Hi,

did you include a SELECT User = @User into the database profiles?
That way you restrict the entity only to the corresponding user.

But please make sure to have an admin profile without restriction ;) (just in case someone clears the entity or to check settings for all users).

Kind regards,
Bettina

Anastasia Pesyakova

Hi Julien,

It's a good idea to apply User selection and a flag that will manage the visibility of a button.

Another option will be to split it by Capsule if possible: Controller (role) will have an access to a Capsule which has the screens with buttons to run allocations / clear data. Reporting user will have an access to a Capsule with reporting screens only, those screens will not have buttons to manipulate data.

The security is easy to manage in this case (using Board native capsule/folder security), and it is not tied to a specific User,it is managed at a Role level.

Hope this helps.

Anastasia

Andries de Vries

Hi Julien,

An extra consideration on top of what Anastasia mentioned above, managing with flags always comes with a risk (you must be sure to have all navigation done by checking the flag, disable screen lists to prevent free flow in the application, etc.). If you have the possibility to split the capsule into two (one for controlling, one for reporting) you are the safest in my opinion.

Andries

Julien CARDON

Hi Andries, Anastasia,

I agree that having separate capsule would be the best option but issue is that we cannot secure capsule in BOARD, only folder.

If I have to create separate folder for each capsule, board structure would be more complicated for end users

Regards

Julien

Julien CARDON

Hello,

Quick question : I have created a generic nested procedure to if my users are allowed or not (IF THEN ELSE). Then I insert this procedure as step 1 of all my critical procedure (and no other change / tests in the main procedure)

The think is that if the user is not allowed to launch the critical procedure, then I there is no way to stop the nested procedure. In all cases it will go back to the main procedure and execute it.

So i'm forced to add some other step in the main procedure to test the result (YES / NO) of the nested procedure

Any tips to stop the nested procedure and the main procedure in case user is not allowed to launch the procedure ?

Regards

Julien