When mass subscribing using format John Doe <john.doe@example.com>, "Members" show some with real name, others without.
GNU Mailman 3.2.0 (La Villa Strangiato):
A list administrator asked me why some people is subscribed with full name and some are not, when he is mass subscribing people using the format John Doe john.doe@example.com. He had experienced this a lot of times.
I tested this several times on my test lists, and one member, who already had his name registrered in Account (Postorius top right), and thus also in Django, kept being subscribed without real name, while the others was subscribed with full name in Members -> Subscribers.
It seems (I’m not certain about this) that the one’s without real name is the one’s already having an account and thus registred in Django (admin/auth/user/), while the ones subscribed with full name associated is the ones not having an account already.
However, as soon as the member (the one with the account) went to Account and changed his real name, the name was immediately associated with the subscription in Members -> Subscribers.
I expect this to be by design, but why isn’t the name associated with the subscription when mass subscribing in the first place, taken from the account?
Henrik Rasmussen
On 10/30/19 2:08 AM, Henrik Rasmussen wrote:
It seems (I’m not certain about this) that the one’s without real name is the one’s already having an account and thus registred in Django (admin/auth/user/), while the ones subscribed with full name associated is the ones not having an account already.
That's probably correct, but not the exact reason.
However, as soon as the member (the one with the account) went to Account and changed his real name, the name was immediately associated with the subscription in Members -> Subscribers.
I expect this to be by design, but why isn’t the name associated with the subscription when mass subscribing in the first place, taken from the account?
To understand, you need a bit of background. The basic engine that
manages lists, subscriptions, users, etc. is Mailman core. Core does not
provide any web UI. It only provides a REST API for use by other
components. It is possible to run Mailman core only without any web UI,
but management would need to be done directly via the REST API and/or
mailman shell which is not particularly convenient.
Because Mailman would not be too useful without a web management UI and a web based archiver, we provide Postorius and HyperKitty for these functions. These are only one possibility. One could build an entirely different web UI or other application to communicate with core via its REST API, but few if any have done so.
Postorius and HyperKitty are Django projects and run under Django. The account that you see (Postorius top right) is a Django account. Core knows nothing about this. Core knows about users and addresses in its own database which is entirely separate from Django's accounts. These user/address records in core is where the user's display_name is kept.
So when a user/address is added to a list, if core already knows that user/address, it just links that to the list and doesn't update the display_name, but if it doesn't know the user/address, it creates it and uses the supplies display name.
It appears there is a mechanism within Postorius to detect a change in the name associated with a Django user and update core, but this is separate from subscribing.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Henrik Rasmussen -
Mark Sapiro