Is there any way to get user role (not user name)?
Is there any way to get user role (not user name)? Probably it possible only with script. Any idea?
Thank you SAU, great solution!
jlin, yes the idea was having filter with expression linked to user setup matrix. After running script you get the user role in the cell of some matrix. Then you can you use it in filter expression to visualize certain items for corresponding role.
But if users on the qloud work at the same time on the same matrix (multi-edit) it will probably cause a conflict.
If I understand Tahir correctly, he believes it would be easier to maintain a model where a single one matrix presents differently (w/ rows & columns filtered depending on user role) versus creating a table view for each role. With multiple table views, any time formatting is updated, multiple views would need to be updated, whereas with a single view, the update only needs to happen one time. If multiple tables needed to have role-based views, the “single table view per role, per matrix” option would create even more maintenance work.
The advantage of role-based filtering becomes even more pronounced if multiple matrices need to present role-based views, and they happen to share the same Categories. Then a single formula that sets defines which Items match the filter could be shared among all the matrices that need to present role-based views.
If Table Views could somehow “inherit” formatting from one another, the “table view per role” might be easier to maintain, but I think it probably would still be more difficult to maintain than the filter technique.
Pls, read again:
“It (A-Script) will give you the message and put the name of the current role in the CUR::CurRole cell for further manipulation“.
What does prevent you from using the Role Name as a parameter for the filter’s expressions?
If I understand correctly, Tahir may have in one matrix (or table view) some sensitive information that should only be shown depending on user role. He desires to use a filter expression that filters rows / columns depending on the detected user role.
By having to manage multiple similar table views (one for each role, one set of views for each matrix), maintaining consistency could be much more difficult, as each time there is a formatting change Tahir would have to make the same change multiple times. On the other hand, one could use a filter expression to make each matrix appear differently per role.
Since the topic is new on the forum, I decided to give the answer to this question to demonstrate the QM capabilities. The TakeCurUserRole A-Script calculates the role of the current model user from the default role list: Modeler, User & Viewer.
**
The TakeCurUserRole A-Script must be run manually because QM is not an event-driven application for the Users…
**
Try switching between roles in any order. After logging in the model with the new role, run the TakeCurUserRole A-Script. It will give you the message and put the name of the current role in the CUR::CurRole cell for further manipulation.
**
The basic principles of the A-Script’s algorithm are described in the comments to it.
**
**
Good luck everyone!
Thank you for your time and efforts! The whole idea was how to provide restricted access to parts of the same matrix for different users without duplicating matrix or view for each user (especially important when you have many users). But it seems technically challenging and as you wrote prone to errors.
As I understand it, the main requirements in your question are that both roles work with the model at the same time, and at the same time do not see the extra information for them. I would have done so. Instead of one matrix M1{Ctg1[A, B], Ctg2[C, D, E]}, I would use two matrices related by Ctg2:
M1{Ctg1[A], Ctg2[C, D, E]} and
M2{Ctg3[B], Ctg2 [C, D, E]}. The M1 matrix is for Role 1, and the M2 matrix is for Role 2. The main advantages of this approach are:
- Role 1 and Role 2 work with different matrices at the same time without conflicting with each other and do not see the information that is not intended for them.
- Simplicity and speed of the implementation, no filters and scripts are needed. The standard tool is used to set the privileges of Role 1 and Role 2.
The way with scripts and filter’s expressions is fraught with errors and incompatibilities between current and future versions of QM and QQ.
Good luck.

Let say we have a category items A and B. I would like Qloud user with Role 1 can see only item A, user with Role 2 only item B. If I have role name i can assign filter using expression. If the user with the Role 1 logged in he will see only A. It could be useful if we have one view where both users entering data. In this case we do not need to create 2 separate Views for each user and set permissions to open component accordingly. Hope it is clearer, it is rather hypothetical case, I do not have model. The question is what happens if both of them simultaneously working on the same matrix?
Let me clarify what I mean.
Imagine that QM has a built-in mechanism to determine the current role of the model user. What should you do with this information? How does the logic or structure of your model depend on the current role of the user? Or in other words. Let the current user role be a model parameter. What in your model depends on this parameter? Access to which components of your model can’t be adjusted by means of permissions for different roles?
If you give meaningful answers to the questions posed, the community will have a chance to give you ideas and tips.
We have several user roles. I would like to find a way (expression or script) to return current user role. {$UserName} returns current user name but I need to get current user’s role name.
To come up with ideas, first need to understand the problem with the role of the model user. So, start by outlining the problem.
Thank you for your time and efforts! The whole idea was how to provide restricted access to parts of the same matrix for different users without duplicating matrix or view (especially important when you have many users). But it seems to be technically challenging and as you wrote prone to errors.