Description of problem: User unable to access SUI if first AD/LDAP group/role does not have feature enabled Version-Release number of selected component (if applicable): 5.8.1.5 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: User denied access to SUI Expected results: Additional info:
If the user's group's role does not have any of the applicable product features assigned the user is not permitted to log into the SUI, this is by design. Could you provide more information about the product features? Or screen shots of the message you see when trying to log in?
The user is in two groups, only one of which has the service catalogue features enabled in the associated role. It seems that CF is selecting the group which doesn't have access, rather than checking all group/role features. Unless ALL the user's groups have the necessary service catalogue features enabled, the user cannot log in.
The roles and product features of the current group are the only ones that will be observed. This discussion cropped up a few times before, ultimately anding all users group roles was decided undesired, so not a bug here operating as designed.
Loic, As Allen stated this has popped up a few times. From a "code" perspective it is working as expected, so this is more of a usability thing. Happy to change it however UXD / PM would like. Sending this to UXD for review / guidance.
@Allen, how does CF determine the current group? Alphabetically or LDAP search priority? As a workaround, we have tried LDAP group priority but this failed. Some way to set this would be helpful.
Groups oder is controlled in Ops UI by using "Edit Sequence of User Groups". @Nick, I will recommend to look into this option and put first your group with the Self Service role enabled. This I think a good workaround for now. @Allen, generally, I think we should authorise user to login anyway and let him selecting another group in the drop down.. (never check but I suspect you can switch between groups). We have in the plan a proper "RBAC" support, which means if nothing is activated for the user in the first group when he is logging in then show nothing in the main body with a message: "your current group does not allow you to access this feature, please change group or contact your administrator"
Created attachment 1320069 [details] screenshot
Created attachment 1320070 [details] screenshot
This is a duplicate of this: https://bugzilla.redhat.com/show_bug.cgi?id=1437682
Brainstorming about this issue, if user logged with a group where he has access to Self Service and then change to a group with no access, what will happen? he will be logged out? We should think about an approach like many UI, they will tell you you are not authorized to view and proposed to user another user.. or Group in our case..
So, I really think that this more of a UX issue vs. a technical one. We've had many conversations about this, and it's working as discussed. So, if we need to change this (which I think we should) this is should be discussed with UXD.
I think what you are hitting is this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1437682 Basically SSUI only looks at current group, not group membership.
*** This bug has been marked as a duplicate of bug 1437682 ***