Re: [Mailman-Developers] Correcting the display name in the recipient address
On Mar 17, 2016, at 11:27 PM, Aditya Divekar wrote:
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:
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:
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'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.
Nice! We can keep the model's intention and have some nice suggestions in the ui.
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
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
On 03/20/2016 06:55 PM, Barry Warsaw 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.
-- 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:
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'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.
Nice! We can keep the model's intention and have some nice suggestions in the ui.
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
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