I have followed the following steps: oo-admin-ctl-team -c create --groups DevGrp --config-file ~/teams.yml This creates the team DevGrp with no members. I then create a team member file: MEMBER|ADD|DevGrp|john,bob and run oo-admin-ctl-team -c sync-from-file --in-file teams.txt I then verify my teams: oo-admin-ctl-team -c list Name:"DevGrp" Maps to:CN=DevGrp,OU=Groups,DC=example,DC=com Members:2 Finally I verify my user: [root@broker ~]# oo-admin-ctl-user -l john User john: plan: consumed domains: 2 max domains: 10 consumed gears: 10 max gears: 100 max tracked storage per gear: 0 max untracked storage per gear: 0 max teams: 10 viewing all global teams allowed: true gear sizes: small sub accounts allowed: false private SSL certificates allowed: false inherit gear sizes: false HA allowed: false I can have 10 teams and viewing all global teams is allowed. When I go to my domain I can click to Add a team... No teams are listed or can be searched for, I am told "You do not have any teams". Looking at the http trace I can see it makes a call to https://broker/console/teams.json?owner=@self which returns an empty json array. If I run https://broker/console/teams.json?owner=john It returns a list of valid teams that I would be able to pick from. Why is @self not working as intended and is there a workaround or fix to this?
Teams created by oo-admin-ctl-team are global teams (not owned by a particular user), so they would never be included in an owner=@self query (owner=john is actually an invalid value for the owner parameter, so that behaves the same as if no owner parameter was specified. A separate http call should be made from the console to search global teams as you type a team's name, something like http://broker/console/teams.json?search=foo&global=true. If you are not seeing that, it means the console does not think that user has the ability to search global teams. Has the user logged out and back in since they were granted the view_global_teams capability?
Yes, all services have been restarted and the user logged out since the user was granted the capability. The issue appears to be case-sensitivity. My instances authenticates against Active Directory and will authenticate many combinations. I executed the oo-admin--ctl-user for "john" but the login to the console was as "John". These are treated as different users who have different permissions. I will close this issue but are there any plans to resolve the case issue. In our real environment users login with their internal SID, a combination of numbers and letters which are always case insensitive on every other system we run.
There is actually work underway to allow for login normalization: https://github.com/openshift/origin-server/pull/5631/files