Opened 9 years ago

Last modified 9 years ago

#372 new enhancement

use email as storage key, add multiple names to email

Reported by: rene / Chris by email Owned by:
Version: 0.9pre3 Keywords:
Cc:

Description

I'm wondering what the purpose is of storing the recipient as the literal of what their entry says? See the attached image:

What happened was that I first emailed the recipient; then I received a response and replied to it. Now I have two entries since the reply filled in their full name as well.

Why not store things on an email basis instead? So that the last-used name for user@… is stored. Instead of having two entries.

I realize the original implementation was probably due to the ease of just having to store one entry per possible-way of typing the recipient, and then do a literal string match.

However, I think the best way to achieve a better system (that avoids duplicates) is to:

  • I think this applies to variation in your stored sender name as well, so everything below applies to that too, except replace the word "Recipient" with "Sender":
  • Split the Recipient field into Recipient Email and Recipient Name.
  • Whenever an email is sent off, analyze the recipient strings, extract the email address and name, then store the email and name. If the email already existed in the database, then store the encountered name for it.

Change History (1)

comment:1 Changed 9 years ago by anonymous

Hi Rene, Chris here.

I just noticed the ticket says "use email as storage key, add multiple names to email" and wondered what you mean by "multiple names to email"? My suggestion was this:

You send an email to a person: Sender: Ricky <dirt at ball dot com> Recipient: foo at bar dot com

Stored: Sender-name: Ricky Sender-email: dirt at ball dot com Recipient-name: (blank) Recipient-email: foo at bar dot com

They reply, this time they replies with a name associated with that mailbox (as always happens when you talk to someone, and they reply with the proper named filled in); AND let's say YOU also change your sender name, so you're replying like this: Sender: Newname <dirt at ball dot com> Recipient: Johnny <foo at bar dot com>

Stored (this updates the old entries for the pair dirt at ball dot com + foo at bar dot com): Sender-name: Newname Sender-email: dirt at ball dot com Recipient-name: Johnny Recipient-email: foo at bar dot com

In other words: Always keep the last-used name for each sender/receiver pair, overwriting whatever the last name was.

The purpose of this is to avoid Virtual Identity Storage Manager from filling up with 2+ entries for everyone you talk to. I've seen as many as 5 entries get created for a single conversation partner just because of small name changes by one or both of us. This fix would solve that. ;-)

Note: See TracTickets for help on using tickets.