Reposting using roundup rather than email because of an old since fixed bug.
Sorry for the duplicate.

Hi William:

 I added Ralf and Bern (other devs) to this discussion.

On Wed, Sep 30, 2026 at 11:15 AM William Sjöblom
<issues@roundup-tracker.org> wrote:
> We have seen an influx of new Chinese `[0-9]+@qq.com` mailing our Roundup instance lately.
>
> When mailgw creates a new user for one of these addresses, the username based on the local 
part
> becomes completely numerical. This in turn causes crashes when clicking the Submit button
> issue.item.html, as the values in `creator`, `nosy`, etc. are treated as IDs instead of 
numerical
> usernames: [...]
> I am aware of the existence of `try_id_parsing='no'`. Unfortunately, these cannot be set for
> properties that are built into the `IssueClass` type (such as `nosy`).

If these are spam, then: https://wiki.roundup-tracker.org/AntiSpam and
https://wiki.roundup-tracker.org/SpamBayesIntegration may be useful.

try_id_parsing can be set, for nosy and default other non-protected
properties, but is
poorly documented. We can document this.

However protected (auditing) properties ( "creation", "creator",
"activity" or "actor") can not have
new definitions assigned in schema.py. But I think (and saw in one
place in the code) the protected
properties only see internal database IDs (e.g. the 20 in user20). I
don't think they are ever
exposed to the username or other user supplied data.

Ralf, Bern does this sound correct?

However William, you said "creator" reports a problem, but you
shouldn't (AFAIK) be able to set creator
from the web interface (raises an error as a protected property) or
anywhere else except direct database
manipulation. Can you verify it's creator that is failing, what the
error is, and how are you trying to set creator?

> I see two possible solutions to this:
>
> 1. Modify mailgw's username generation to prefix the resulting numerical usernames with a 
letter.
> 2. Modify the template userauditors to add a letter to the username before inserting it into 
the
> database.
>
> Before fixing this in our instance, I'd be curious to hear which, if any, of the proposed 
solutions
> would be preferred by upstream.

Neither, but not having users with purely numeric email addresses
would be best 8-). But that's not
something we can control.

To address nosy, you can change your IssueClass to add:

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

and similar for other link/multilinks to the user class. AFAIK this
should not be a problem, but I suggest
backing up the db for safety just in case.

This ability is "documented" in
https://www.roundup-tracker.org/docs/upgrading-history.html#journalling-changes
at the end of the section (look for nosy). The up side is that you
don't have to do username munging. The down
side is that changes are scattered across properties in the schema,
but does use the override mechanism
Richard developed to handle this case.

AFAICT the override mechanism not documented anywhere else. William,
where were you looking for info on
solving your problem?

I was thinking describing this mechanism in the references.txt published as
https://www.roundup-tracker.org/docs/reference.html#classes-and-properties-creating-a-new-
information-store
section just before the Methods section header. The other place I
could document it is in the IssueClass section
(the section after Methods).

However, Bern and Ralf, I'm wondering if we could simplify this. The
"try_id_parsing" option appears to be
a class-level setting rather than a property-level one that points to
the class. I can't think of a situation
where different Link() or MultiLink() properties pointing to the same
class would need different "try_id_parsing"
values.

I suggest adding a `_try_id` property (default True) to class Class
and Class.settryid(enabled) Class.tryid()
(alternate name suggestions welcome) methods similar to
setorderprop/orderprop etc. The default value
of try_id_parsing for any properties pointing to that class will use
the _try_id value.

Ralf you added try_id_parsing, so thoughts?

For William's case, calling `user.try_id(False)` will make any
property that points to the user class default to
try_id_parsing=no. Calling Class(.., try_id_parsing=True/False) will
explicitly set the value overriding the default.

So one addition to schema.py "fixes" all the references he has to the
user class.

Quips, comments, evasions, questions or answers?

--rouilj