SchoolTool imported bugs have invalid reporters

I didn't set the SchoolTool bug import to verify the email addresses when importing people (the circumstances differed to the Ubuntu Bugzilla import where we could assume that all users had given permission for Canonical to email them).

Since this may occur in future imports, perhaps malone should handle this case.

On Mon, Feb 19, 2007 at 09:18:00PM -0000, James Henstridge wrote:
> I didn't set the SchoolTool bug import to verify the email addresses
> when importing people (the circumstances differed to the Ubuntu Bugzilla
> import where we could assume that all users had given permission for
> Canonical to email them).
>
> Since this may occur in future imports, perhaps malone should handle
> this case.

I've mentioned this a few times before without getting any response, but
I'm saying once again, please don't do any imports without verifying the
users until these issues have been resolved.

I agree that Malone maybe should handle cases like this, but this is far
from the only case that needs to be fixed. It's also not clear, what
does it mean to be subscribed to a bug, but not get any e-mail
notifications? It's not an easy problem to solve, it requires a spec to
be written first. So for now I consider the bug importer to be buggy, as
it doesn't respect the interface declarations. To fix this bug in the
short term, I think the user should either be verified, or unsubscribed
from the bug.

Well, we can pretty easily change this (it is trivial to identify all the users created by the import who don't have validated email addresses by looking at the creation rationale).

The intent was for everything to just work for users who were already using Launchpad, and for people who created an account later on to also find their bugs. Maybe there are good reasons not to do this though.

One way of handling this would be showing the inactive subscribers as Ignoring subscribers -- a tick next to people who were getting mailed about the bug report, a cross next to people who weren't. (This would be forward-compatible with using the same indicator to show whether people were in holiday mode, bug 44542.)

On Wed, Feb 21, 2007 at 02:05:44AM -0000, Matthew Paul Thomas wrote:
> One way of handling this would be showing the inactive subscribers as
> Ignoring subscribers -- a tick next to people who were getting mailed
> about the bug report, a cross next to people who weren't. (This would be
> forward-compatible with using the same indicator to show whether people
> were in holiday mode, bug 44542.)

Yeah, that would work. However, that doesn't solve the problem
completely. Another thing is if the assignee or reported is invalid, you
can't search for bugs assigned/reported by them on the advanced search.
There's probably a few other cases like this as well, that's why I want
a spec to be written instead of a bunch of quick hacks.

This should be fixed before the final zope3 import.

Stuart has merged the second Tom Hoffman account which has fixed the problem for bug 80195, but does not address the root cause.

Also, from Mark on IRC:

16:26 <sabdfl> jamesh, BjornT, stub: malone should learn to deal with inactive users who are subscribers to bugs.
16:27 <sabdfl> - we have a "subscribe someone" feature, which should allow you to subscribe someone who is not active, AND should let you create a profile for an unknown user and mail them in the process.... they will be inactive till they respond
16:27 <sabdfl> - people will want to be able to "become inactive", and if they are subscribers to bugs we don't want malone to OOPS

The bug notification code actually copes with invalid subscribers without any problems. What caused an OOPS here was that the reporter was an invalid Person. Unsubscribing him from the bug wouldn't have helped.

To me, the solution is that the reporter should not be treated specially here -- in particular not used in the From: address of this sort of bugmail. Here are two bugs that derive from that: bug 94321 and bug 130222

I think this might have been fixed by the change to bugmail. Perhaps not.

The Bugs team has done a lot of bug imports this year and none of us can remember hitting this problem, so I'm going to take a leap and assume it's not an issue any more.