Hi William:

I have updated the IssueClass section of the docs to read:

====
IssueClass
~~~~~~~~~~

IssueClass automatically includes the "messages", "files", "nosy", and
"superseder" properties. You can override the default configuration of
these properties by defining them in your IssueClass. For example::

  issue = IssueClass(..., nosy=Multilink("user",
                     try_id_parsing="no"), ...)

would disable id parsing forcing lookup by username even if the
username is numeric.

The messages and files properties list the links to the messages and
files related to the issue. The nosy property is a list of links to
users to tell about changes to the issue. They get "CC'ed"
====

Is that sufficient?

> I'm not sure which way forward is best. A class-level try_id_parsing
would fix our
> case with a couple of lines in schema.py,

Given the search issue that Ralf brought up, I wonder if this is a good
idea. Maybe
we should add some friction to using try_id_parsing.

> while a mailgw username template would
> avoid creating ambiguous usernames in the first place. What I want to
underline
> is that addresses in this format are in active use and in many cases
completely
> legitimate. Since the stock templates break on them out of the box, I
think it's
> worth tracking either way.

You don't need a template, we could add an auditor for create and set on
the user class.
It would:

  1) on create change an all numeric username to some value (e.g. add
the first element
     of the domain and an underscore as a prefix (12345@qq.com ->
qqa_12345), If the username
     is unique, set the returned username prop accordingly. If not
unique, add some salt to
     the name until it is unique.

  2) on set, raise an exception that the username is not acceptable.

implementation thoughtfully considered 8-).

The user will have to be notified of their username. I am not sure we
have a notifier or
anything to do that. If the user only communicates via email, it's not
an issue.

I am not sure what happens if two different joes: joe@somewhere.com and
joe@overthere.com
both email the tracker. Can't have two 'joe' usernames. This argues for
the auditor and not
just a template to create a unique name. On the web, you are just told
to choose a new name
and associate your email with it. Over email that's not possible.

I think this is a better way to handle it than adding try_id_parsing to
the class.

Ralf thoughts?