Looks like another encoding bounce issue. Ralf on Oct 1, 2026, 1:28 PM said:

On Thu, Oct 01, 2026 at 04:41:38PM +0000, John Rouillard wrote:
>  I added Ralf and Bern (other devs) to this discussion.
>
> On Wed, Sep 30, 2026 at 11:15 AM William Sjoblom
> <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 seems to be the problem. Fully numeric properties confuse the
parser because they are taken for IDs in the database. So when you input
a numeric username it will think its the ID.

> 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 think when e.g. trying to search for creator or some other property
that is a Link/Multilink to the user class with a fully-numerical
username will confuse the parser. So it thinks you're searching for the
creator being user12345 when in fact you're searching for the user with
the *username* 12345.

> > 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.

Maybe we can create a configurable template for user creation via
mailgw. This could add a prefix or suffix and/or mandate the use of the
full email address for the username. I think many web services today use
the email address for good reasons...

> 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.

Yes, I think so, too in the meanwhile, I was unsure when I implemented
this as a Link/Multilink property.

> 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.

Why not also call it 'try_id_parsing'? It would be the default for
Link/Multilink properties to that class but an explicit Link property
would win over this default?

> 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.

Yes, I think that would be nice.

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

It has other problems, though, in the API you can no longer search for
user IDs when this is turned off.