-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Addressbook computation algorithm change: Spec #338
Comments
Using Bush small and jeb@jeb.org initially, I got Jeb Bush listed in the correspondent list. However, after adding jeb@bush-brogan-2002 as trusted email address, Jeb Bush disappear from the correspondent list. Will continue testing with Fikes. |
please see Chinmay's specifications |
For every correspondent, there will be 3 columns in total. Messages sent, Messages received, Messages received from the owner Message sent- number of messages where this correspondent is as a sender. |
ver Jan 16 |
Add "Archive owner email address" under "More". Although we can add this information in Edit Correspondent, our system (via browser) is not good at editing a big address book. ADDED - Jan 20 version |
System somehow treats some email as correspondent name. Example: brankel@eog.state.fl.us |
It seems "Received messages" count messages "To" the designated correspondent/address. It should include "cc/bcc" as well. |
Need to update Advance Search: |
Should we have 2 fields?
Total Messages
Messages sent by archive owner
…On Fri, Jan 18, 2019 at 9:08 AM Peter Chan ***@***.***> wrote:
Need to update "Information about this archive"
from
Messages: 123
Incoming: 234
Outgoing: 345
Images: 234
Documents: 345
Others:456
to
Messages: 123
Images: 234
Documents: 345
Others:456
[image: screen shot 2019-01-17 at 6 15 01 pm]
<https://user-images.githubusercontent.com/1050899/51364034-72317480-1a8f-11e9-9926-b73b8e9de590.png>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#338 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA-JP-aQsWKthCTXP1eJQ2IXG0512Y1Uks5vEUGwgaJpZM4ZG_PS>
.
|
Or |
Did you make sure that the same mail id did not appear in more than on contact? |
@chinuhub Sorry. After further verification, message counts after changes in email owner are correct. |
feature added |
Provide a set of email addresses as trusted one.
If sender is a trusted mail address-
Call process contact with all name-email pairs (appearing anywhere in this message’s header) as trusted ones.
if sender is not a trusted email address-
Call process contact with all name-email pairs (appearing anywhere in this message’s header) as non-trusted ones.
If non-trusted name-email pair then don’t do unification based on name (but the unification based on email is still done). After that, just add the name in the contact.
If trusted name-email pair then perform the unification as done earlier.
Case 1.
Suppose we have two name-email pairs appearing in the archive.
Fikes notification@linkedin.com and Moore notification@linkedin.in
Earlier these two were being unified because of the common mail id. As a result, these two different names were being put in the same contact. It resulted in those names being in the same contact with proper names of Fikes like
Richard Fikes
Richard L. Fikes
Fikes
fikes@cs.stanford.edu.in
After the algorithm change, now there will be a new contact with email id as notification@linkedin.com and names of Fikes, Moore etc. being together in that contact.
** Case 2 **
[Not addressed in modified algorithm] if someone sends a mail to
Dummy fikes@cs.stanford.edu and fikes@cs.stanford.edu is a trusted email address:
If this mail was sent from a trusted name-email pair:
Then this association is a trusted one and unification will be based on ‘dummy’ as well as on email address.
If this mail was sent from a non-trusted name-email pair:
Then this association is non-trusted so no unification will take place based on "dummy" but unification will take place based on email. It results in "dummy" being added to the contact where fikes@cs.stanford.edu is a valid email address.
The text was updated successfully, but these errors were encountered: