Webscreen view based on Role

Webscreen view based on Role

  

I am very new to the web platform.  I have a webscreen where the preparation at the moment is based on the user id.  I would like to have the screen show the users data when the user is logged in and show the users group when his manager is logged on.

I spent the last hour and a half looking through the knowledge base and have not found the answer.

Have mercy on a web noob, It is probably staring me right in the face

Thanks 

If you go to the logic tab, scroll down to Roles, you can view your roles there.

For each role there are 3 actions available, CheckRole, GrantRole and RevokeRole.

You can use CheckRole to find out wether the current user is a Manager or regular user:
CheckManagerRole(GetUserId())

If the user is a Manager, you can show extra details on the screen using an IF statement for example.

So use an if in the preparation logic based on group and role, then run the aggregate based on that logic?

It doesn't have to be in the preparation, you could place an IF widget on screen and only show a certain section (like the group part) if the User is a Manager.

If you wish to optimize performance you could also choose to add an IF in your preparation, where you would only run the aggregate based on wether the user is a Manager or not.

OK, now I'm lost.  I have a role set up in my module but when I go to assign the user to the role in the users screen it does not give me the option to assign the role to the user

Hmm that's pretty weird, maybe you have to set the role to public?

Andrew Finkelstein wrote:

OK, now I'm lost.  I have a role set up in my module but when I go to assign the user to the role in the users screen it does not give me the option to assign the role to the user

You published the module?
You need to publish so that the Role is stored in the system database.


Joey Moree wrote:

Hmm that's pretty weird, maybe you have to set the role to public?

A role does not need to be public to be visible in the Users application :)

It need to be published (and sometimes, refresh the user page so that its load).


Thank you both for the help.  The publish and refresh did the trick

Andrew,

If the manager sees something completely different from a user that is not manager, this is a case (imho) to use two different pages.

Keep different concepts separated, and you will reduce application complexity.

If you still want to use the same page, in the case the USER data is a form or something like that, and the user group is a LIST, use separeted web blocks (each with its own preparation), one that shows the USER data, other the shows the LIST.

In the page, you use an IF (widget), with the condition set to check if the logged user is a MANAGER (CheckManagerRole() if your role is called Manager), and in case this is True, shows the web block for the manager, otherwise shows the web block for the user.

This way you keep everything isolated.

Eduardo-

I would like to have a screen that shows the work done by a salesman if they log in.  I would like to display the same screen with a whole division if the manager logs in.  What would be the best way to do that?

Joey Moree wrote:

It doesn't have to be in the preparation, you could place an IF widget on screen and only show a certain section (like the group part) if the User is a Manager.

If you wish to optimize performance you could also choose to add an IF in your preparation, where you would only run the aggregate based on wether the user is a Manager or not.

Using aggregates/SQL in IF branchs in the preparation is considered bad practice.

https://success.outsystems.com/Documentation/Best_Practices/Performance_Best_Practices/Performance_Best_Practices_-_Logic

Avoid using queries inside ‘If’ branches in preparation


Description

Avoid using the conditional queries in preparation to prevent the extra query data from going to the viewstate.


Solution

When using refresh screens, take care with conditional queries (queries in "if" branches). To prevent this, declare a local screen variable and assign it from the query and with an empty record list in the beginning of the preparation.


Importance

If a query is only executed inside an “if” branch in the preparation and used outside that branch (in a table records, for example), its data need to be always in viewstate. This is because the query is only executed sometimes. This increases the page viewstate size.


Remarks

Note that this only happens if we use the submit action that terminates with an end node (causing the screen to refresh). For AJAX actions and for destinations, this does not apply.


Cheers.


Andrew Finkelstein wrote:

Eduardo-

I would like to have a screen that shows the work done by a salesman if they log in.  I would like to display the same screen with a whole division if the manager logs in.  What would be the best way to do that?

It depends on what information are you showing and how and maybe other details I don't know.
 
But in general, I would do the following (assuming that the information will be shown in the same way, in both cases.

In the Preparation:

Add the aggregate to fetch information.
As a filter, you can use something like this:

(CheckManagerRole() and YourEntity.Division = Division) OR YourEntity.UserId = GetUserId()

This will fetch all records for a given division if the user logged is a Manager, or only the records associated with the user itself.

In the screen, add a LIST record that uses as Source List the output of this aggregate, and you can than build the line template for each line.

This way, you don't need to do anything separated.

Think this can help you?

Cheers.

Eduardo Jauch wrote:

Joey Moree wrote:

It doesn't have to be in the preparation, you could place an IF widget on screen and only show a certain section (like the group part) if the User is a Manager.

If you wish to optimize performance you could also choose to add an IF in your preparation, where you would only run the aggregate based on wether the user is a Manager or not.

Using aggregates/SQL in IF branchs in the preparation is considered bad practice.

https://success.outsystems.com/Documentation/Best_Practices/Performance_Best_Practices/Performance_Best_Practices_-_Logic

Avoid using queries inside ‘If’ branches in preparation


Description

Avoid using the conditional queries in preparation to prevent the extra query data from going to the viewstate.


Solution

When using refresh screens, take care with conditional queries (queries in "if" branches). To prevent this, declare a local screen variable and assign it from the query and with an empty record list in the beginning of the preparation.


Importance

If a query is only executed inside an “if” branch in the preparation and used outside that branch (in a table records, for example), its data need to be always in viewstate. This is because the query is only executed sometimes. This increases the page viewstate size.


Remarks

Note that this only happens if we use the submit action that terminates with an end node (causing the screen to refresh). For AJAX actions and for destinations, this does not apply.


Cheers.


Thanks for clearing that up Eduardo!


As for Andrew, like Eduardo said previously, you are adding more and more concepts to this screen.
To prevent it from getting too big (which causes it to become unreadable/a drag to work in) you could best create different screens.

For each screen you can setup roles, to allow which roles are able to access those screens.
Next you could create a single landing page, which checks the users role and then redirects them to the appropriate screen (so a navigate in your preparation).

Lastly, if there are elements you wish to show on multiple screens (lists or details for some kind of entity) you could create a webblock so you can easily share those on multiple screens.

Thank you all for the help.  Are any of you aware of any of the Outsystems online classes that would go into depth on how to use groups and roles?  It would be greatly appreciated