Warn if assigning a bug to someone not involved with the project

I'd suggest an Undo button/link right beside the message, similar to what gmail does when you, for example, delete an email.

Or perhaps the text "No bugs in %(context)s have been assigned to %s before. Is he a new developer?"

Perhaps you don't want to use "developer" there, but rather "contributor" or something similar. In Ubuntu, for instance, there are many people who aren't official developers that are assigned bugs.

Per the comments on bug 138504, I really think confirmation would be better. It will be hit so rarely in normal use that it should not cause annoyance or habituation. Kiko's phrasing is fine, except that obviously he may be a she.

Marking as affecting a new product (eg https://bugs.edge.launchpad.net/bzr/+bug/148737/+choose-affected-product) does currently have a confirmation step.

I had a very productive chat with ~sinzui about this, and we got a plan:

* We check for two levels of appropriateness: users that have any bugs assigned to them at all and users that are related to the project (they are either driver, owner, or have a bug in the project assigned to them) or any of the above indirectly, via team membership.
* When a user submits a form assigning the bug to someone, we check for these two conditions. If the assignee violates one of them, we continue to a new page, where the user will be presented with a warning, and will be able to select one of two options - `Continue` or `Back`. Choosing `Continue` will submit the changes and take the user back to the bug page, choosing `Back` will take the user to the bug page with the form prefilled with the values previously entered (so that they can change only the assignee). It may be nice, if possible, to also force-expand the form using JS.

Automatically expanding the relevant line in the table would be nifty. But please, if at all possible, accept the changes immediately and provide an undo button instead of asking for confirmation.

> Automatically expanding the relevant line in the table would be nifty

Working on it.

> But please, if at all possible, accept the changes immediately and provide an undo button instead of asking for confirmation

It's not, in fact, possible (I'm happy to discuss, elsewhere, what is necessary for allowing this sort of interaction within LP - I think it's a great idea)!

> > But please, if at all possible, accept the changes immediately and
> provide an undo button instead of asking for confirmation
>
> It's not, in fact, possible (I'm happy to discuss, elsewhere, what is
> necessary for allowing this sort of interaction within LP - I think it's
> a great idea)!

So do you mean that you'd get a dialog saying

  Assigned to john (John Galt)
  John Galt has not previously participated in this project or had a
bug assigned.
  Is this ok?

  [No, undo assignment to John] [Yes, continue]

--
Martin

I don't understand what it would mean to have a "No, undo" button alongside a "Yes, continue" button. Either the reassignment has happened, in which case "continue" would be a no-op, or it hasn't happened, in which case "undo" would be incorrect.

All that would be necessary for an "Undo" button would be a <form> with a hidden assignee field representing the previous assignee, so clicking the button would reassign back to him/her.

On Nov 20, 2007 4:00 PM, Matthew Paul Thomas <email address hidden> wrote:
> I don't understand what it would mean to have a "No, undo" button
> alongside a "Yes, continue" button. Either the reassignment has
> happened, in which case "continue" would be a no-op, or it hasn't
> happened, in which case "undo" would be incorrect.
>
> All that would be necessary for an "Undo" button would be a <form> with
> a hidden assignee field representing the previous assignee, so clicking
> the button would reassign back to him/her.

"Continue" would just be a way to navigate away from the notification.

I suppose it could just be a box displayed on top of the bug page, in
which case you're right, just an "undo" would be enough.

I still see some nuisance caused by the wrong assignee getting mail,
by them potentially being shown a private bug, and so on. But I can
see the downside of confirmation boxes too.

--
Martin

Reported bug 164196 about the wrong assignee receiving a notification when they shouldn't.

On Tue, Nov 20, 2007 at 05:00:31AM -0000, Matthew Paul Thomas wrote:
> All that would be necessary for an "Undo" button would be a <form> with
> a hidden assignee field representing the previous assignee, so clicking
> the button would reassign back to him/her.

What's the use case for completely undoing the assignment? If you
assigned the bug to the wrong person, you most likely want to assign it
to someone else than the previous one, otherwise you wouldn't have tried
to reassign it in the first place.

Wouldn't it be better to provide a "Change" button/link rather than
"Undo"?

That's a good point: in this case "Change..." would be more appropriate than "Undo".

The implementation of this on edge.lp at the moment is very annoying for archive administration people. When we fix a bug to which the archive team is subscribed, we tend to assign it to ourselves. As we get bugs for a whole lot of packages, having to click through a full extra screen for each sync, component change or similar is going to be a fairly large time sink. Please at least remove the confirmation screen when a bug is assigned to the person doing the assigning.

another complaint bug about this is at https://bugs.edge.launchpad.net/malone/+bug/173195

Fixed in mainline r5264