Closed Bug 1336033 Opened 9 years ago Closed 9 years ago

Correct treestatus scopes dervived from vpn_sheriff and vpn_treestatus LDAP groups

Categories

(Taskcluster :: Operations and Service Requests, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: garbas, Unassigned)

References

Details

User Story

1. I would need to change the scope on role mozilla-group:vpn_sheriff
replace ``project:releng:treestatus/sheriff`` with ``project:releng:treestatus/admin``

2. I need to also create ``mozilla-group:vpn_treestatus`` with ``project:releng:treestatus/sheriff`` scope
1. I would need to change the scope on role mozilla-group:vpn_sheriff replace ``project:releng:treestatus/sheriff`` with ``project:releng:treestatus/`` 2. I need to also create ``mozilla-group:vpn_treestatus`` with ``project:releng:treestatus/sheriff`` scope
User Story: (updated)
Please ignore my comment and follow instructions in User Story.
As discussed with Rok on IRC: This should give the TB/SM people kent@caspia.com, clokep@patrick.cloke.us, aleth@instantbird.org, ewong@pw-wspx.org, mozilla@jorgk.com (and more?) from the vpn_treestatus group their rights back.
Blocks: 1284476
Where did the original setup of scope take place? I'm struggling to find a papertrail of where review and sign-off of the new treestatus took place (especially for permissions parts). It's just that the permissions were regressed once already when treestatus was moved into the releng system the first time (bug 1214391), and now we've had something similar again.
(Adjusting summary to make this bug easier to find)
Summary: Change scopes on existing role and add new role → Corrent treestatus scopes dervived from vpn_sheriff and vpn_treestatus LDAP groups
Summary: Corrent treestatus scopes dervived from vpn_sheriff and vpn_treestatus LDAP groups → Correct treestatus scopes dervived from vpn_sheriff and vpn_treestatus LDAP groups
:emorley: The only one to blame for this is me. I poorly planned the credentials/auth migration. Now that I understand the RelengAPI/LDAP/... more I can make sure this doesn't happen in the future. Actually, everything was planned I should just a request this change before I started the migration. Again, sorry for the disruption, I hope that I can make it up with a better UX/UI of TreeStatus. Now that the east coast is up I am going to ping on #taskcluster to push on this.
No problem - many thanks for your hard work getting it migrated, it's great to see Treestatus getting some long-overdue TLC :-)
https://tools.taskcluster.net/auth/roles/#mozilla-group:vpn_sheriff https://tools.taskcluster.net/auth/roles/#mozilla-group:vpn_treestatus (scopes also prefixed with `assume:`) I can't provide guidance on whether these changes are appropriate/acceptable, but at least we have this bug trail. :-)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Nice that you fixed the bug, but I still don't have access to change the tree status, for example for https://mozilla-releng.net/treestatus/show/comm-aurora-thunderbird. Apparently some "Update" button should be visible.
Flags: needinfo?(rgarbas)
Flags: needinfo?(pmoore)
:Jorg K: are you logging via okta? or via Email?
Flags: needinfo?(rgarbas)
Flags: needinfo?(pmoore)
I can't speak for jorgk, but I logged in via okta and don't see any features to make modifications to the treestatus.
Jorg, Patrick, Note, if you log in via okta, to use the LDAP address with the appropriate commit level access (which might not be a @mozill.com email address).
Sorry folks -- there's a whitelist to which new groups need to be added. I added vpn_treestatus to it just a few minutes ago, so please logout, log back in with Okta and your LDAP account, and you should be OK. Sorry for the confusion :(
dustin, that seems to have fixed it for me! Thanks.
Logged in via Okta/LDAP. I get the "Update Tree" button now. Thanks.
Hmm, another problem. In order to make the "Update" button at the bottom right active, you need to select a Status. Previously you could just change the Message of the Day without changing the Status. Can you restore the previous behaviour?
Jorg, can you create a separate bug for that?
Flags: needinfo?(jorgk)
Flags: needinfo?(jorgk)
Many thanks Jorg. :-)
See Also: → 1336103
Component: Service Request → Operations and Service Requests
You need to log in before you can comment on or make changes to this bug.