[Mailman-Developers] Questions in regard to the database operations

[Danci Emanuel]

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 user`s
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? 
 
Thanks again,
Emanuel 


________________________________
 From: Barry Warsaw <barry at list.org>
To: Danci Emanuel <danci_emanuel at yahoo.com> 
Cc: mailman-developers at python.org 
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 security-team at example.com.  For convenience, you want to allow
people to post to security at 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 security at example.com, it gets forwarded to
security-team at example.com, but Mailman will not see the list's posting address
in the To header.  Without security at example.com 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[]=database 
>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:

anne at example.com
aperson at example.com
anne.x.person at 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 security-team at example.com, 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 anne at example.com, then when new messages are posted to
the mailing list, only anne at example.com 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('anne at 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,
                                   'security-team at example.com',
                                   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 Systers` schema, 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.

Cheers,
-Barry