131
Views
5
Comments
Solved
Access to OSSYS_ESPACE_SCREEN_ROLE
Question

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

mvp_badge
MVP
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.

mvp_badge
MVP

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

mvp_badge
MVP

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.

mvp_badge
MVP
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.

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

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.