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.