Re: [Mailman-Developers] Correcting the display name in the recipient address
On Mar 17, 2016, at 11:27 PM, Aditya Divekar wrote:
Suppose you have a user with two linked addresses, one of which is the preferred address. Only the preferred address has a display name, and the user does not. Now in the scenario where the other linked address(not the preferred one) is subscribed to a mailing list without providing a display name, it would be natural to check if the user has a display name, and use that if it exists. But the user too does not have a display name in this case. In such a case should we perform a further check and try to use the preferred address's display name if it exists or simply use an empty string instead?
In the opinion I gave, in case we are not supplied with a display name, we should check the user display name followed by the preferred address display name, and use them in the specified order respectively. If none exist, empty string would be used.
In a more general scenario, as pointed out by Barry to question this method, suppose a user has multiple linked addresses, only one of which has a display name, and its neither the preferred address, nor the subscribed address. Should the display name search algorithm find that one too, since it still is a linked address for the user and hence contains valid user information?
One other comment. In the more general case I outlined (i.e. your last paragraph), *if* we decide to use display_names in other linked addresses, we can only use ones that are associated with validated addresses. A user's preferred address will always be validated.
The other thing about the more general case is that there's no natural ordering. So yes, we could use the preferred address first, and then pick an arbitrary ordering criteria for falling back to all linked, validated addresses. That could be alphabetical by email address, or chronological by validation or registration date.
Cheers, -Barry
On 03/20/2016 06:55 PM, Barry Warsaw wrote:
On Mar 17, 2016, at 11:27 PM, Aditya Divekar wrote:
Suppose you have a user with two linked addresses, one of which is the preferred address. Only the preferred address has a display name, and the user does not. Now in the scenario where the other linked address(not the preferred one) is subscribed to a mailing list without providing a display name, it would be natural to check if the user has a display name, and use that if it exists. But the user too does not have a display name in this case. In such a case should we perform a further check and try to use the preferred address's display name if it exists or simply use an empty string instead?
I wonder if we aren't over thinking here. Maybe I didn't associate a display name with my user record and my alternate address on purpose for my own reasons. Maybe when I subscribe my alternate address to some list, I do it because I don't want my preferred address or its display name associated with this subscription.
I'm not sure we should be mining the data for things that the user may have intentionally not provided.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mar 20, 2016, at 08:15 PM, Mark Sapiro wrote:
I wonder if we aren't over thinking here. Maybe I didn't associate a display name with my user record and my alternate address on purpose for my own reasons. Maybe when I subscribe my alternate address to some list, I do it because I don't want my preferred address or its display name associated with this subscription.
I'm not sure we should be mining the data for things that the user may have intentionally not provided.
That's an interesting point, thanks.
The intention in the model is that the user's display name can be used as a fallback for any linked address that has no display name. So I still think it makes sense that if an address with no display name is subscribed and the user record it's linked to does have a display name, we should use that. But if it doesn't, then we don't go hunting around ("mining") for something else to use, especially on a record that's not directly subscribed to the mailing list.
Cheers, -Barry
Barry Warsaw writes:
On Mar 20, 2016, at 08:15 PM, Mark Sapiro wrote:
I wonder if we aren't over thinking here. Maybe I didn't associate a display name with my user record and my alternate address on purpose for my own reasons. Maybe when I subscribe my alternate address to some list, I do it because I don't want my preferred address or its display name associated with this subscription.
I'm not sure we should be mining the data for things that the user may have intentionally not provided.
That's an interesting point, thanks.
I'm with Mark here.
I think the right thing to do is to file an RFE with Postorius to have the "link new address" screen "suggest" the existing display names, but not automatically add any.
The intention in the model is that the user's display name can be used as a fallback for any linked address that has no display name.
Also have a "inherit user name" value in the list. Despite the way I lean above, this could be default. But definitely EIBTI (@aditya "explicit is better than implicit") -- we should not take None for "carte blanche".
Steve
On Mar 23, 2016, at 12:03 AM, Stephen J. Turnbull wrote:
I'm with Mark here.
Okay cool, I think we're all in agreement about how this should behave.
I think the right thing to do is to file an RFE with Postorius to have the "link new address" screen "suggest" the existing display names, but not automatically add any.
Nice! We can keep the model's intention and have some nice suggestions in the ui.
The intention in the model is that the user's display name can be used as a fallback for any linked address that has no display name.
Also have a "inherit user name" value in the list. Despite the way I lean above, this could be default. But definitely EIBTI (@aditya "explicit is better than implicit") -- we should not take None for "carte blanche".
I certainly agree as far as mining for display names in linked, but not subscribed, addresses. However, I do want to keep the intended semantic that if the *subscribed* address has no display name, we fall back to the linked user record. The idea is that a user can set their display name once, in their user record, and won't need to set it every time they link (and validate) a new address to their profile.
Aditya, do you think you have enough information to finish up mr !104?
Cheers, -Barry
Hi!
I certainly agree as far as mining for display names in linked, but not
subscribed, addresses. However, I do want to keep the intended semantic that if the *subscribed* address has no display name, we fall back to the linked user record. The idea is that a user can set their display name once, in their user record, and won't need to set it every time they link (and validate) a new address to their profile.
Aditya, do you think you have enough information to finish up mr !104?
So according to what I've gathered from the conversation, the fall back on the user name can be made implicit. The user name is to be always used in case of missing display name for the subscribed address. The feature for suggesting the display names from the other records i.e. linked via the user, but not subscribed, could, as suggested, be raised in postorius for the UI part.
@Barry The mr code would first check if a display name is provided while
subscription i.e. member.address.display_name.
If not, it will check if the linked user has a display name and use that if
it exists i.e. member.user.display_name. And as a final case when both
these fail, it will use an empty string.
I'll go ahead and make these changes.
Thanks!
Aditya
participants (4)
-
Aditya Divekar -
Barry Warsaw -
Mark Sapiro -
Stephen J. Turnbull