Question about adding addresses using the REST API
Mailman3 experts --
It is clear from many aspects of the documentation that mailman3 may have addresses in its database that are not connected to any user. I would like to create such addresses using the REST API.
The REST API documentation does not suggest this is possible, nor does trying an obvious POST request to the addresses collection work (returns a 405 error).
The only way I've found to create addresses with the REST API is to create users.
The only way I've found to create a standalone address (not linked to any user) is to create a user with that address, unlink the address, then delete the user.
Is there a more straightforward way to just create an address with no user?
Thanks!
-- Stephen Daniel
Stephen Daniel writes:
The only way I've found to create a standalone address (not linked to any user) is to create a user with that address, unlink the address, then delete the user.
Is there a more straightforward way to just create an address with no user?
I don't think so. Normal operation of Mailman and its associated applications assumes that addresses are linked to users. I imagine you can get unexpected and unwanted behavior if you create such addresses. Offhand, I can see no reason why we should support it. There's also this comment in rest/addresses.py:
# But really, it should not be legal to subscribe an
# address to a mailing list that isn't controlled by a user -- maybe!which suggests somebody thought it is a bad idea.
On 1/15/22 10:03 AM, Stephen Daniel wrote:
The only way I've found to create a standalone address (not linked to any user) is to create a user with that address, unlink the address, then delete the user.
Is there a more straightforward way to just create an address with no user?
The more straightforward way is via the IUserManager create_address method. This method is not exposed directly in REST, so you can't do it via REST.
My question is why do you want to?
Granted when an unknown nonmember address posts to a list we create a standalone address record, but maybe we should be creating a user too. We don't because it's tricky. Suppose User A with address A posts to a list from nonmember address B. We create the standalone address B record as a nonmember, but now user A can add address B as another address. If we also created User B, this would not be possible.
But again, what is your use case for creating standalone addresses?
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
TL;DR: Listening to the advice, I will create and manage user/address pairs.
I am in the process of porting a web site that is used to manage a small organization. The web site maintains a directory of users of that organization, and also allows them to subscribe/unsubscribe to a small set of interest-group mailing lists for that organization. The users are not tech savvy, and are not expecting or expected to manage their subscriptions through Postorius, nor do they have access (normally) to the archives. Indeed, the URL to Postorious will normally be turned off at the reverse proxy server that sits in front of both Postorious and the organization's website.
The one-source-of-truth is the website's database. The website code has callouts for "subscribe <address> to <list>" and "unsubscribe <address> from <list>".
I am trying to minimize the amount of code I write to implement the web site's callouts, to initialize the mailing lists when I port the organization to this new implementation, and make it relatively easy to keep the website's database and mailman3's database in sync.
The impression I had from the docs was that unlinked addresses were a first class object. Since my website callouts only deal with addresses, this seemed a good mapping. However, I understand from this email thread that unlinked addresses are not the way to go, so I'll map <address> in the website database to <user>/<address> in mailman3.
Thanks for the advice and feedback!
-- Stephen Daniel
On Sat, Jan 15, 2022 at 2:27 PM Mark Sapiro mark@msapiro.net wrote:
On 1/15/22 10:03 AM, Stephen Daniel wrote:
The only way I've found to create a standalone address (not linked to any user) is to create a user with that address, unlink the address, then delete the user.
Is there a more straightforward way to just create an address with no
user?
The more straightforward way is via the IUserManager create_address method. This method is not exposed directly in REST, so you can't do it via REST.
My question is why do you want to?
Granted when an unknown nonmember address posts to a list we create a standalone address record, but maybe we should be creating a user too. We don't because it's tricky. Suppose User A with address A posts to a list from nonmember address B. We create the standalone address B record as a nonmember, but now user A can add address B as another address. If we also created User B, this would not be possible.
But again, what is your use case for creating standalone addresses?
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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/
Stephen Daniel writes:
I am in the process of porting a web site that is used to manage a small organization. The web site maintains a directory of users
The one-source-of-truth is the website's database. The website code has callouts for "subscribe <address> to <list>" and "unsubscribe <address> from <list>".
Are users identified by their email addresses? That is, is it intentional that they never have more than one email address for organizational use? What happens if someone changes their address?
In your use case, it probably doesn't make much difference, but if there's more to a user in the directory than their email address, and they have an identity separate from the address (eg, they can change their address and keep their identity), mapping directory users to Mailman users is probably conceptually cleaner, even though you use the email address as the "name" of the user in talking to Mailman.
I am trying to minimize the amount of code I write to implement the web site's callouts, to initialize the mailing lists when I port the organization to this new implementation, and make it relatively easy to keep the website's database and mailman3's database in sync.
In your place, I would design the interface so that the user's primary address (not the specific address, but the user's attribute) is the only address used to subscribe to the lists.[1] Then if a user changes address, you change the primary address attribute, and automatically all the user's lists will go there. If you use "bare" Address objects, you will need to change each subscription individually.
I don't know if there's any use to having continuity of users, if all users have the same settings. But if some users want and get different settings, this allows them to keep those settings across address changes and across subscriptions, changing them only in one place as necessary. At present your users don't care, but (in general, your organization may be different) there may be future requests for extensions to the website, and I think directory user <-> Mailman user will make those simpler.
The impression I had from the docs was that unlinked addresses were a first class object.
They are, in the sense that to Python they exist as objects and to Mailman there is a collection of them that can be searched and enumerated. But Mailman is designed with the "sophisticated user" in mind: people with multiple addresses, who want to customize their subscriptions per-subscription, and in that sense Mailman manages user objects and delegates subscription and address management to the user.
Since my website callouts only deal with addresses, this seemed a good mapping. However, I understand from this email thread that unlinked addresses are not the way to go, so I'll map <address> in the website database to <user>/<address> in mailman3.
I would think of this as a join of the user tables on <address>, since in both your directory and Mailman each address identifies a unique user. That's true as long as you have no "free-standing" Addresses in Mailman.
Steve
Footnotes: [1] IIRC, this is implemented internally by subscribing the User object rather than an Address object to the list.
Thanks for the thoughtful feedback. It's really helpful.
The organization's current website is old, and at some point due for major upgrades. At the moment, my task is to move it from a set of servers operated privately by one of our members onto resources we control, and update the software stack to something current. So I'm moving it to Google Cloud and using Mailman3 instead of Mailman2. There is some urgency to this task, so I'm planning to live within the well-defined callouts the site makes for "subscribe" and "unsubscribe".
Once this transition is done I need to do a major overhaul, starting with formal requirements gathering, leading to design improvements, etc. During this phase I will tackle tighter coupling of the website database and mailman3's database. I expect this to include allowing people access to the Postorious interface, allowing them to manage their subscriptions with Postorious, if they choose, while continuing to support the simple checkboxes in the website for people who want to keep it simple and don't want to learn new things.
In this context, I will certainly design around your comments that the mapping should be between website user and mailman3 user.
Thanks again!
-- Stephen
On Sat, Jan 15, 2022 at 10:45 PM Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:
Stephen Daniel writes:
I am in the process of porting a web site that is used to manage a small organization. The web site maintains a directory of users
The one-source-of-truth is the website's database. The website code has callouts for "subscribe <address> to <list>" and "unsubscribe <address> from <list>".
Are users identified by their email addresses? That is, is it intentional that they never have more than one email address for organizational use? What happens if someone changes their address?
In your use case, it probably doesn't make much difference, but if there's more to a user in the directory than their email address, and they have an identity separate from the address (eg, they can change their address and keep their identity), mapping directory users to Mailman users is probably conceptually cleaner, even though you use the email address as the "name" of the user in talking to Mailman.
I am trying to minimize the amount of code I write to implement the web site's callouts, to initialize the mailing lists when I port the organization to this new implementation, and make it relatively easy to keep the website's database and mailman3's database in sync.
In your place, I would design the interface so that the user's primary address (not the specific address, but the user's attribute) is the only address used to subscribe to the lists.[1] Then if a user changes address, you change the primary address attribute, and automatically all the user's lists will go there. If you use "bare" Address objects, you will need to change each subscription individually.
I don't know if there's any use to having continuity of users, if all users have the same settings. But if some users want and get different settings, this allows them to keep those settings across address changes and across subscriptions, changing them only in one place as necessary. At present your users don't care, but (in general, your organization may be different) there may be future requests for extensions to the website, and I think directory user <-> Mailman user will make those simpler.
The impression I had from the docs was that unlinked addresses were a first class object.
They are, in the sense that to Python they exist as objects and to Mailman there is a collection of them that can be searched and enumerated. But Mailman is designed with the "sophisticated user" in mind: people with multiple addresses, who want to customize their subscriptions per-subscription, and in that sense Mailman manages user objects and delegates subscription and address management to the user.
Since my website callouts only deal with addresses, this seemed a good mapping. However, I understand from this email thread that unlinked addresses are not the way to go, so I'll map <address> in the website database to <user>/<address> in mailman3.
I would think of this as a join of the user tables on <address>, since in both your directory and Mailman each address identifies a unique user. That's true as long as you have no "free-standing" Addresses in Mailman.
Steve
Footnotes: [1] IIRC, this is implemented internally by subscribing the User object rather than an Address object to the list.
participants (3)
-
Mark Sapiro -
Stephen Daniel -
Stephen J. Turnbull