It's not possible to set someone else as bug supervisor
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Abel Deuring |
Bug Description
What happens:
If you try to set someone else who isn't a team as bug supervisor, you get an OOPS: OOPS-1409H2046, OOPS-1409S143. UserCannotSubsc
What should happen:
It should be possible to set another person as bug supervisor, as long as that Person is not a team of which you're not an admin. William Grant described the issue in a comment on bug 438985 thus:
"Reading the view code also revealed another issue: there is a permission conflict. When setting the bug supervisor, you can set it to any person, or a team you administer. This implicitly adds a structural subscription for them. In other places you can only subscribe *yourself* or a team you administer. The latter restriction is now implemented in the model, so attempting to set the bug supervisor to another non-team person will fail similarly. I'm not sure how best to resolve this one."
Changed in malone: | |
milestone: | none → 3.1.11 |
description: | updated |
Changed in malone: | |
assignee: | nobody → Abel Deuring (adeuring) |
Changed in malone: | |
status: | Fix Committed → Fix Released |
I discussed this with Graham, and we identified two problems:
1. Making it possible to appoint everybody (except teams you don't administer) may lead to an unpleasant suprise for a supervisor who isn't aware of the consequesnces of his new role: lots of bug mail. riptionTargetMi xin._userCanAlt erSubscription( ) already has a special case when the subscription target is an IDistributionSo urcePackage, where more people are allowed to subscribe somebody else. Adding another special case, in this case for the new subscriber getting the "new hat" of a bug supervisor would make the code even more convoluted.
2. The current permission check for structural subscriptions in StructuralSubsc
Especially issue 1 needs a bit more discussion. Our idea is to implement a process, where a person/team is first proposed to become the bug supervisor, and where the proposed person/team can then explicitly accept or decline this role.
This is a bit outside of the scope of fixing an OOPS, so we'll leave the permissions as they are right now. To fix this bug, I'll only catch the exception lthat leads to the OOPS and show the user a polite error message.