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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
