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,
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.
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.
Jimmy Klaver
Jimmy Klaver wrote:
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.
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