[PATCH] models: Don't munge the 'From' field of patches

[Doug Anderson]

Jeremy,

On Mon, Sep 30, 2013 at 3:18 PM, Jeremy Kerr <jk at ozlabs.org> wrote:
> Hi Doug,
>
>> I can put it on my list of things and try to get to it over the next
>> few weeks.  If we can come up with a simple solution then it will be
>> easier to find time.  ;)
>>
>>
>> So I think that the two "simple" solutions I can think of are one of these two:
>>
>> 1. Just add a "From" field in the Web UI in the case that the
>> "Submitter" and "From" are different.  That would also match the code
>> I already wrote.
>>
>> 2. Assign a unique submitter ID every time an email comes in with a
>> different Real Name (but the same email address).  You could auto-lump
>> these into someone's account if they've logged in to patchwork.
>>
>> Basically there are lots of places in the UI (the filter UI, search
>> results view, etc) that assume that a single submitter ID matches to a
>> single real name, so showing anything other than the official
>> "Submitter" name as the Submitter seems wrong.
>
> Been thinking about this a little, and this is what I think would be best:
>
> When a patch or comment comes in, we still lookup a submitter id by
> case-insensitive search on the email address field. This sets the
> submitter FK on the Patch/Comment object.
>
> However, the web view and mbox downloads use the actual From: header as
> the display & download. We could either extract this from Patch.headers
> in the view function (check out the usage of HeaderParser in
> patch_to_mbox), or save the full From: value as an additional field in
> the Patch object. Comments can continue to use Person.name.
>
> List views should still use the Person object to show the submitter, and
> we still use the person FK in filter-by-submitter.
>
> However, we should keep the Person.name field current, so that the list
> views reflect reality. When a mail comes in, we should update
> Person.name to what's in the From field, provided it's non-empty (and
> doesn't already match, to avoid an extra DB write). This way, patchwork
> doesn't persist with the first mail's From header.
>
> How does that sound?

Sounds reasonable to me, except I'd modify it to say that we don't
update the Person.name field for anyone who has actually ever logged
into patchwork.  This allows people who care to prevent abuse.  I can
just imagine someone sending some sort of email with my email address
and the real name "Captain Dumbohead".  It would update things
everywhere!  ;)

The above also seems like something I could conceivably tackle, so
I'll put it on my list and try to get to it in the next few weeks.

-Captain Dumbohead