Syncing Real Name between user account and membership
Hi together,
a user was mass-subscribed (with a wrong name) and now registered and changed his name via the web interface but the list entry is not changed.
On looking further at that, I got to the following json outputs:
curl -urest:pass http://localhost:8001/3.0/addresses/user@example.com/user { "created_on": "2020-11-26T15:43:24.928285", "is_server_owner": false, "self_link": "http://localhost:8001/3.0/users/123456", "user_id": 123456 "display_name": "Fixed Name", }
curl -urest:pass http://localhost:8001/3.0/addresses/user@example.com { "email": "user@example.com", "original_email": "user@example.com" "registered_on": "2020-11-26T15:43:24.896405", "self_link": "http://localhost:8001/3.0/addresses/user@example.com", "display_name": "Broken Name", "verified_on": "2020-11-26T15:43:24.965784", "user": "http://localhost:8001/3.0/users/123456" }
Should the fix of the name propagate? Or what would be the appropriate action here?
Regards, Andi
On Thu, Dec 17, 2020, at 6:12 PM, Andreas Barth wrote:
Hi together,
a user was mass-subscribed (with a wrong name) and now registered and changed his name via the web interface but the list entry is not changed.
On looking further at that, I got to the following json outputs:
curl -urest:pass http://localhost:8001/3.0/addresses/user@example.com/user { "created_on": "2020-11-26T15:43:24.928285", "is_server_owner": false, "self_link": "http://localhost:8001/3.0/users/123456", "user_id": 123456 "display_name": "Fixed Name", }
curl -urest:pass http://localhost:8001/3.0/addresses/user@example.com { "email": "user@example.com", "original_email": "user@example.com" "registered_on": "2020-11-26T15:43:24.896405", "self_link": "http://localhost:8001/3.0/addresses/user@example.com", "display_name": "Broken Name", "verified_on": "2020-11-26T15:43:24.965784", "user": "http://localhost:8001/3.0/users/123456" }
Should the fix of the name propagate? Or what would be the appropriate action here?
Address and User (/user endpoint in first output) are separate entries in Mailman and are allowed to have separate names. Until recently, the Addresses' display_name attribute was immutable via REST API, however that has been fixed and will be included in next release of Mailman Core.
You can update the display_name of an address using "mailman shell" for now using the commands in the documentation1
>>> from mailman.interfaces.usermanager import IUserManager
>>> from zope.component import getUtility
>>> user_manager = getUtility(IUserManager)
>>> addr = user_manager.get_address('fperson@example.com')
>>> addr.display_name = "Fixed Name"
>>> commit()
THis should hcnange the name of `fperson@example.com).
-- thanks, Abhilash Raj (maxking)
Andreas Barth writes:
a user was mass-subscribed (with a wrong name) and now registered and changed his name via the web interface but the list entry is not changed.
I don't recall the design discussion, but I'm pretty sure that this distinction was intentional. The idea was that people might want to have different display names associated with different addresses (eg, you probably don't want your User display name associated with an address you use on anonymized lists). I'm not sure that option has any merit in practice.
@ Abhilash:
Since Postorius doesn't provide a way to manage address-specific display names, we should probably have Postorius propagate display name changes. I believe that is normally what the user wants.
What does everybody think?
On Sat, Dec 19, 2020, at 10:42 AM, Stephen J. Turnbull wrote:
Andreas Barth writes:
a user was mass-subscribed (with a wrong name) and now registered and changed his name via the web interface but the list entry is not changed.
I don't recall the design discussion, but I'm pretty sure that this distinction was intentional. The idea was that people might want to have different display names associated with different addresses (eg, you probably don't want your User display name associated with an address you use on anonymized lists). I'm not sure that option has any merit in practice.
@ Abhilash:
Since Postorius doesn't provide a way to manage address-specific display names, we should probably have Postorius propagate display name changes. I believe that is normally what the user wants.
What does everybody think?
+1, I've been thinking the same.
I am just wondering if Core's API should do this (probably not by default, but with a bool parameter that P can use every time), or should we iterate over all addresses and PATCH the display names in them (would be slower, with multiple API requests).
I am leaning towards the first option. What do you think?
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj (maxking)
- Abhilash Raj (maxking@asynchronous.in) [201219 06:28]:
I am just wondering if Core's API should do this (probably not by default, but with a bool parameter that P can use every time), or should we iterate over all addresses and PATCH the display names in them (would be slower, with multiple API requests).
I am leaning towards the first option. What do you think?
I agree to that.
Also, I'm just trying to do a small sync script for the moment (using mailman release 3.3.2) for user in client.users: if not user.display_name: continue for address in user.addresses: if address.display_name == user.display_name: continue address.display_name = user.display_name address.save() and getting the response urllib.error.HTTPError: HTTP Error 405:
Also the server side log doesn't tell me more: [19/Dec/2020:14:00:00 +0100] "PATCH /3.1/addresses/aba@ayous.org HTTP/1.1" 405 0 "-" "GNU Mailman REST client v3.3.2"
Any hint what I'm doing wrong here?
Regards, Andi
On Sat, Dec 19, 2020, at 6:55 PM, Andreas Barth wrote:
- Abhilash Raj (maxking@asynchronous.in) [201219 06:28]:
I am just wondering if Core's API should do this (probably not by default, but with a bool parameter that P can use every time), or should we iterate over all addresses and PATCH the display names in them (would be slower, with multiple API requests).
I am leaning towards the first option. What do you think?
I agree to that.
Also, I'm just trying to do a small sync script for the moment (using mailman release 3.3.2) for user in client.users: if not user.display_name: continue for address in user.addresses: if address.display_name == user.display_name: continue address.display_name = user.display_name address.save() and getting the response urllib.error.HTTPError: HTTP Error 405:
Also the server side log doesn't tell me more: [19/Dec/2020:14:00:00 +0100] "PATCH /3.1/addresses/aba@ayous.org HTTP/1.1" 405 0 "-" "GNU Mailman REST client v3.3.2"
Any hint what I'm doing wrong here?
Currently released versions doesn't allow updating Address's display_name (which is the only editable attribute, hence 405 PATCH method not allowed error). This is something that I fixed 3 days back, so it will only be available by next release.
You can iterate over the Users and their addresses in mailman shell
as well:
>>> from mailman.interfaces.usermanager import IUserManager
>>> from zope.component import getUtility
>>> user_manager = getUtility(IUserManager)
>>> for user in user_manager.users:
... for address in user.addresses:
... address.display_name = user.display_name
...
>>> commit()
This should do the same thing you mentioned above I think.
Regards, Andi
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj (maxking)
- Abhilash Raj (maxking@asynchronous.in) [201219 14:54]:
Currently released versions doesn't allow updating Address's display_name (which is the only editable attribute, hence 405 PATCH method not allowed error). This is something that I fixed 3 days back, so it will only be available by next release.
Oh, didn't realize it was that recent. Thanks for your work! (As I run mailman from git, I might just upgrade to that patch then)
Regards, Andi
- Abhilash Raj (maxking@asynchronous.in) [201219 14:54]:
You can iterate over the Users and their addresses in
mailman shell
as well:>>> from mailman.interfaces.usermanager import IUserManager >>> from zope.component import getUtility >>> user_manager = getUtility(IUserManager) >>> for user in user_manager.users: ... for address in user.addresses: ... address.display_name = user.display_name ... >>> commit()
I think it would be useful (for others who try it) to have just these snippets somewhere (also as examples what could be achived by mailman shell). I'm happy to add them myself if possible, but the wiki seems to be mailman 2 centric?
What would be the appropriate place then?
Regards, Andi
On 12/31/20 2:52 AM, Andreas Barth wrote:
I think it would be useful (for others who try it) to have just these snippets somewhere (also as examples what could be achived by mailman shell). I'm happy to add them myself if possible, but the wiki seems to be mailman 2 centric?
What would be the appropriate place then?
The wiki <https://wiki.list.org/> is an appropriate place. It only seems to be Mailman 2 centric because it's been around in one form or another for over 20 years and during much of that time, there was no Mailman 3 at all.
There is also a new FAQ section at <https://docs.mailman3.org/en/latest/faq.html>, the source for which is at <https://gitlab.com/mailman/mailman-suite-doc/-/blob/master/source/faq.rst>. Merge requests to add to that are also welcome.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [201219 06:13]:
Since Postorius doesn't provide a way to manage address-specific display names, we should probably have Postorius propagate display name changes. I believe that is normally what the user wants.
I fully agree, it's AFAICS even what the user expects.
Regards, Andi
participants (4)
-
Abhilash Raj
-
Andreas Barth
-
Mark Sapiro
-
Stephen J. Turnbull