Access to OSSYS_ESPACE_SCREEN_ROLE

Hi,

As suggested in the title, does anyone know where the roles per screen are stored (in the database)?

The reason I ask this is because I want to check what roles are linked to a particular screen in order to make a function to check whether a user has access to a particular screen.

I don't want to create a container per menu item with a display property where i manually have to check the role using the checkuserrole function. I want to create a generic function that checks the roles that are allowed on a certain screen, and then verify it against the roles the user has.

Does anyone have an idea on how to achieve this?

Kind regards,

Jimmy

Hi Jimmy,

I know you can access a list of Screens in the OSSYS_ESPACE_SCREEN table, but I'm not aware of the Role-Screen association being exposed on a table.

You could implement this by having a table where you associate your Screens (that you load from the OSSYS_ESPACE_SCREEN table) with your Roles (the public Roles table in the System section of the Dependencies). Then your function would lookup this data.

Hi Afonso,


Then I would have to keep track of roles per screen in my own entity..which would mean I have to manage my roles per screen apart from managing the checkboxes on the screens in service studio. That doesn't sound like a great option..

Thanks for thinking with me.

Kind regards,

Jimmy Klaver

Solution

Hi Jimmy,

As far as I know, this information is stored in the module itself, not as metadata.
Being like this, It is not really possible to do what you want.

I understand what you want to avoid (and it makes sense), and I think you should create an IDEA (in the Ideas area of the site) to ask OutSystems to implement a built-in function that you can pass a user and a screen identifier (??) and it returns if the user has access to it.

This would really make the definition of menus easier.

Cheers.

Solution

Jimmy Klaver wrote:

Hi Afonso,


Then I would have to keep track of roles per screen in my own entity..which would mean I have to manage my roles per screen apart from managing the checkboxes on the screens in service studio. That doesn't sound like a great option..

Thanks for thinking with me.

Kind regards,

Jimmy Klaver

It's an extra step, but a side effect is that you'll have everything you need to replace the checkbox functionality in Service Studio - you'll have a function to check for user acess (your equivalent of the CheckRole function) and a way to associate roles with screens (your equivalent of the checkboxes). There wouldn't be a need to manage both at that point.

It could be too much work if all you require is a way to check for menu permissions, but if your application ends up requiring a more finegrained permission system, it's something to consider.

Thank you for bringing attention to an interesting problem.

Hi,

I've chosen to go back to using a check per item, basically hardcoding the user access. As you said Afonso, it requires too many changes in the application to make a "dynamic" authorization functionality possible. I'll create an idea in the idea section about this.

Thanks for the help guys