329250 - Need capacity for product-based administrators

Status: VERIFIED FIXED

(Webtools Graveyard :: Litmus, defect)

Description

[Chris Cooper [:coop] (he/him)]

We would like to allow other Mozilla-based projects to control their own testcases and testgroups in Litmus. However, the current Litmus authentication system is binary: users either have global admin privileges, or none.

We should continue to have global admin privileges for true admins/QA staff, but we should also allow certain users to have admin control over the testcases associated with their specific products. I think per-product is the right level of access control here, but am willing to debate the subject if someone thinks differently.

Comment 1

[Zach Lipton [:zach]]

Coop: want me to take this one so you can keep plugging away on your test run work? 

I think per-product is the right level of control here as well. This gives us:

* Litmus admin - superuser, can give other users administrator permissions, create new products, edit system parameters, etc...
* User admin - can reset users' passwords, disable accounts, etc... 
* Product admin - can manage testgroups, subgroups, and testcases for a particular product 

My main question here is what we want to do with edit_categories. Categories like platform and opsys are currently global to all products (Bugzilla works the same way) so product admins should not be able to edit those, but product admins should be able to manage testdays for their product only. What if testday management got moved out into a separate "Manage Testdays" admin page, making category editing superuser-only but testday managegment available on a per-product basis? 

Am I missing anything else? I'll keep the overall group architecture open (similar to Bugzilla) so that new levels of permissions can be added as Litmus evolves. 

Comment 2

[Chris Cooper [:coop] (he/him)]

(In reply to comment #1)
> Coop: want me to take this one so you can keep plugging away on your test run
> work? 

That would be great, Zach. Getting test runs done is the priority right now for me. I was hoping to get this particular bug taken care of by Christmas. Does that timeframe work for you?

One thing we should discuss is how the ranking of things like test runs and testdays is going to work if both MozQA people and community product admins are creating them. I'm fine with having community product admins able to create both test runs and testdays, but the ranking of these should probably be gated MozQA admins to make sure there are no scheduling conflicts.

Comment 3

[Zach Lipton [:zach]]

That timeframe should be good for me as well. 

I agree that some level of oversight over testruns/days by the QA team is necessary. Realistically, I don't think we're going to have more then a fairly small, relatively well known group of people creating runs, so we should be able to set some guidelines with Calendar QA and other teams and fix issues as they come up; I'm not sure if a whole separate "rank testdays" function is really needed. If we find it's a problem, we can always add that later down the road.

One other design point for future reference: the group architecture needs to be open enough to also handle restricted groups of tests, e.g. security tests, CJK tests, or other MoCo only data. Actually implementing that is a separate bug, but the same backend and permission-granting UI can be used for both.

Comment 4

[Chris Cooper [:coop] (he/him)]

(In reply to comment #1)
> My main question here is what we want to do with edit_categories. Categories
> like platform and opsys are currently global to all products (Bugzilla works
> the same way) so product admins should not be able to edit those, but product
> admins should be able to manage testdays for their product only. What if
> testday management got moved out into a separate "Manage Testdays" admin page,
> making category editing superuser-only but testday managegment available on a
> per-product basis? 

The only possible exception I can think of: we *might* want to give product admins access to the testday section on the edit_categories page. However, I could also see the value in gating testday requests through Litmus superusers so that we don't end up with conflicting testdays. 

I'd say require superuser access for edit_categories to start, and if we end up fielding too many requests from product admins, we can consider opening parts up to them.

Comment 5

[Zach Lipton [:zach]]

That sounds like a good plan. The backend is mostly built out on this, and I'll get the UI side going. 

Comment 6

[Zach Lipton [:zach]]

Fix has been checked in and the production install was updated last night with no reported negative feedback. Currently, all former administrators have super-user permissions. I'll send mail to the QA list today about changing some users to product admins for their respective products.