Thank you very much for the clarifications, Barry! Now everything is clear!
In regard to the aliases, based on you suggestions I will find a proper way to link the addresses (aliases) to a certain user hence solving the problem elegantly with the already existing 'resources'.
As for the latter problem, I still have something in mind. If we were to choose the
second option (the one which implies setting the flag "delivery_status" to the proper
value) does this not mean that we will have to keep the user
s preferences alive, without deleting them? I am thinking about a solution to avoid keeping the users
preferences, but please correct me if I am wrong. Could not we add a flag to the
'user' table (e.g: unsubscribed, deleted), flag that will hold the value 1 if the user
is unsubscribed and 0 otherwise. Although your solution will work as a wonder, if I
got everything wright, adding the flag to the 'user' table will save us some memory.
Do you think I should add that flag to the 'user' table, or should I just adapt the code so
that the "delivery_status" will be properly changed when a user is unsubscribed?
From: Barry Warsaw email@example.com To: Danci Emanuel firstname.lastname@example.org Cc: email@example.com Sent: Monday, June 25, 2012 9:39 PM Subject: Re: [Mailman-Developers] Questions in regard to the database operations
On Jun 25, 2012, at 08:02 AM, Danci Emanuel wrote:
I still want to ask you something. As far as I am aware, I also have to implement the aliases feature as Systers see it, meaning that a user, after gets registered can post messages to a mailing list from more than one address.
Ah, so this is totally different than "acceptable aliases" and the IAcceptableAliasSet interface. What I described earlier is a mailing list feature which lets you set up a posting address alias in your MTA.
For example, let's say you create a mailing list for your security team and you call it firstname.lastname@example.org. For convenience, you want to allow people to post to email@example.com and so you set up an alias in your MTA's configuration file (e.g. /etc/aliases) which points security -> security-team.
When people post to firstname.lastname@example.org, it gets forwarded to email@example.com, but Mailman will not see the list's posting address in the To header. Without firstname.lastname@example.org being added to the mailing list's acceptable_aliases, these posts will be rejected with an "implicit destination" error.
But none of that really applies to your use case. ;)
So, just to make sure, do you think that these addresses could be added directly to the address table and then all the addresses (aliases) linked to the same user? This - http://systers.org/systers-dev/doku.php/systers_database_in_postgresql?s%5B%... is the current database schema implemented by Systes, so basically I am looking a solution to replace the 'alias' table.
Remember the model I described earlier, regarding addresses, users, and members? Using this model, you can register multiple address objects and link them to the same user. E.g. you could register all of the following:
email@example.com firstname.lastname@example.org email@example.com
(Let's assume too that all three have been validated.)
and link those addresses to the user record representing Anne Person. When Anne subscribes to a mailing list, such as firstname.lastname@example.org, she chooses one of those three addresses to subscribe using the 'member' role. This is the address that will receive postings to the list.
So if she subscribes email@example.com, then when new messages are posted to the mailing list, only firstname.lastname@example.org will receive copies.
However, Anne can *post* to the mailing list with any of her three validated and linked email addresses, and no further moderation approval is necessary. This is one of the big advantages of the mm3 model over the mm2 model. We now *know* that all three of those addresses are associated with Anne, so any of her addresses are allowed for posting. However, she will only receive copies of list posts to the addresses she's explicitly subscribed, IOW she won't receive three copies of list postings unless she wants to.
In summary, the mm3 model directly supports the Systers model, as I understand it. All the internal APIs are there to add additional addresses, verify them, link them to users, and subscribe them to mailing lists. All you have to work out is the social and procedural ways of getting those additional addresses into the system, verified, and linked to the user.
Furthermore, in regard to the user removal, if the address and the user records remain in the database, how can we know if a user has been unsubscribed from the list?
You know because there will be no member record linking any of the user's addresses to the mailing list. There are various ways using the internal API to check this. Probably the easiest is to use something like the following:
from zope.component import getUtility from mailman.interfaces.member import MemberRole from mailman.interfaces.subscriptions import ISubscriptionService from mailman.interfaces.usermanager import IUserManager
service = getUtility(ISubscriptionService) manager = getUtility(IUserManager)
# Find the user record for the user linked to this email address. anne = manager.get_user('email@example.com') if anne is None: # not found
# Search for all of Anne's subscriptions on the security team, but ignore # any where she is a list admin or moderator. for member in service.find_members(anne.user_id, 'firstname.lastname@example.org', MemberRole.member): # Iterate over all of Anne's memberships on this mailing list.
I am asking this, because in order to successfully implement the dlists, we need to keep account of the unsubscribed users, so that we won
t send any unwanted emails to them. In the aforementioned Systersschema, this is done by setting the 'deleted' flag to true.
Although you can easily tell whether someone is subscribed to a mailing list or not, you can't really tell if they were once subscribed but now are not. mm3 just doesn't keep a record of that.
Now, there are a couple of ways we could allow a plugin to know that. One thing to do is to add an event which gets triggered when an unsubscription occurs. Then your plugin could register interest in that event and record it in whatever local database it uses. That would be pretty easy to add.
Another way to do it would be to not actually unsubscribe the member, but instead to disable delivery of the member. It would have the same effect of inhibiting delivery of list posts, but it would keep the member record in the database. Each IMember has a "delivery status" flag which contains an enum value indicating whether delivery is enabled or disabled (the latter with various possible reasons).
If you used this approach, you'd have to amend the .find_members() code above to check member.delivery_status.