700482 - Need to be able to grant users access to only edit mirrors

Status: REOPENED

(Webtools :: Bouncer, defect, P1)

Description

[Dave Miller [:justdave]]

I can't find an appropriate permission in bounceradmin to grant someone access to edit mirrors.  Does such a thing exist, and can we get it added if not?

This is a high priority item, we need this in place to set up volunteer mirror admins which mrz's been advertising about already.  We were thinking bounceradmin had this already, and went to set it up and couldn't find it.

Comment 1

[Fred Wenzel [:wenzel]]

Anthony is at Velocity Conf and Mozcamp this week, but assigning it to him so it's on his radar.

Comment 2

[Fred Wenzel [:wenzel]]

Poking around a little bit: When solving this, keep in mind that currently the write API is restricted to "staff only", while "staff" is the fancy word for "everyone who can see the admin panel". So the API permissions need to be fixed in the same process.

Docs are here: https://docs.djangoproject.com/en/1.2/topics/auth/#permissions

Comment 3

[matthew zeier [:mrz]]

Hey guys, can I get an idea of an ETA here?  I have a list of mirror volunteers and now with the sysadmin agreement, all are asking "how do I get started!?"

Looking for something so I can set my expectations.

Comment 4

[Fred Wenzel [:wenzel]]

Anthony is looking forward to working on this but still has a few bugs to tie up on his current project before he can get started here. I expect it to be another weekish before he can have a serious look at this. Thanks for bearing with us!

Comment 5

[Michael Morgan [:morgamic]]

Anthony - can you give an update on progress here?  Thanks.

Comment 6

[Fred Wenzel [:wenzel]]

Sorry, we had higher-priority projects that took precedence so far, so we didn't get to this. That said, Anthony should have time to look into this again.

Like I said in comment 2, we *do* need to separate API access from "is staff" so that not everyone who can log in has full API rights. Volunteers could then be "staff" and we could try and use Django's built-in rights management to limit access to certain mirrors only, probably by making a new group "volunteers" that just has those rights.

Anthony, can you investigate what needs to be done here, and give a time estimate when how long that would take you? Thanks!

Comment 7

[Anthony Ricaud (:rik)]

Django admin might provide a simple way to do that. That depends on the exact needs you have.
Dave: Could you elaborate a bit on the exact use-case behind "editing mirrors"?

Django admin allows to give a user permission to add, change or delete mirrors. There's no sense of ownership though: users with delete permission can delete all mirrors.

Would you like them to be able to edit Locations, OS and/or Products too?

Comment 8

[Dave Miller [:justdave]]

As long as we're going that tack, we do have a use case for Locations/OS/Products, but it's not for this.  If it can be implemented similarly then it would still be useful.

The people we would be using as volunteer admins would need read/write access to:
GeoIP > Countries
GeoIP > IP Blocks
GeoIP > Regions
Mirror > Mirrors

It would also be useful if they could create new users, but NOT be able to grant those users any special privileges (because this is how we enter the mirror contacts).  Editing users would probably be good, too, as long as they can't edit users who have been granted privileges.  Basically, just be able to edit name, email address, mailing address and IRC nick on users who aren't staff.

The separate use case for Products/OS/Location would allow us to grant, for example, people from the SeaMonkey project access to do their own data entry for new downloads without allowing them to screw with other stuff.  This is already covered on bug 546264.

Comment 9

[Anthony Ricaud (:rik)]

I've got the code mostly done for the first use case.

I think we shouldn't let people manually edit IP Blocks. This table is erased every month on the 10th for GeoIP updates so people should file bugs to add exceptions in there.

For the creating/editing of users, I'll do some testing to see if django permissions allow what you're asking. If it doesn't, we'll open a new bug to track this.

Comment 10

[Anthony Ricaud (:rik)]

I've opened bug 730321 to track the creation/edition of users.

Comment 11

[Anthony Ricaud (:rik)]

This landed with https://github.com/fwenzel/tuxedo/pull/7

Comment 12

[Anthony Ricaud (:rik)]

So this is deployed to stage. You can test through https://tuxedo.stage.mozilla.com. If you need an account, send me an email. We need to test that you can add volunteer admins and that they have the right set of permissions.

After this is tested, we'll push this to production.

Comment 13

[Laura Thomson :laura]

Who needs to test this?  Brandon and I can drive this to prod, but I'm not sure what the blocker is.

Comment 14

[Dumitru Gherman [:dumitru]]

I don't think this is needed any more...

Comment 15

[Jake Maul [:jakem]]

I'm pretty sure we don't need this anymore. The only mirrors we use nowadays are Mozilla-controlled ones (I'm slowly disabling all the community mirrors, since we've moved to CDN for product delivery), so there's nobody other than staff that would have a mirror to control in the first place.

Comment 16

[Brandon Savage [:brandon]]

I'm happy to wontfix this then.

Comment 17

[Brian Hourigan [:digi]]

Per #c15 W/Fing this

Comment 18

[Stephen Donner [:stephend] Not actively reading bugmail]

As this was WONTFIX'd, Web QA didn't touch this as part of our verification chain for Bouncer 2.0.

Verified WONTFIX, per the above comments.

Comment 19

[Robert Helmer [:rhelmer]]

So I've been working on fixing up bouncer's unit tests, and this change broke some of them which I am getting close to finishing. However, I notice that the bug was WONTFIX'd while it appears to have actually landed in comment 11 - which is it? :)

Was there some part of this bug that did not land?

Comment 20

[Anthony Ricaud (:rik)]

It seems it has landed: https://github.com/mozilla/tuxedo/commit/e7474f4cefc92562528808272e8e14eeebaa31f2.

Comment 21

[Robert Helmer [:rhelmer]]

(In reply to Anthony Ricaud (:rik) from comment #20)
> It seems it has landed:
> https://github.com/mozilla/tuxedo/commit/
> e7474f4cefc92562528808272e8e14eeebaa31f2.

Thanks! So the migration has already been run and we've been operating this way for quite a while - it looks like in addition to "staff" there is a group which includes all permissions, and it appears that all users are part of this group.

Should we back this out or just continue forward? I investigated backing out and I think undoing the migration is the only tricky bit (there's an easily-resolved conflict in the code but that's it). However I feel more inclined to keep it at this point since it is not getting in the way and the risk of keeping it feels lower than backing out at this point.

Comment 22

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)