On Jun 12, 2015, at 08:00 PM, Nafisa Shazia wrote:
My main question is: How deep do I need to go into the subscription workflow to add a single field?
Steve provided some good background and answers, and I'll just add a few more thoughts.
The subscription workflow stuff was added fairly late in the 3.0 cycle and I had to give up on a few things to make this work. Most importantly was the idea of attaching additional information to the subscription request, e.g. the preferred delivery mode (regular or digest).
The subscription workflow is interesting because there are steps which need to be persistent. This happens when a confirmation is required from the user, or an approval is required from the list moderator. In those cases, we need to store the state of the workflow in the database, keyed off a token, and then reconstitute the workflow when that token is presented, either in an email or through the REST API. In order to simplify, we only persist the the most important bits of the subscription request, and things like the delivery mode didn't make the cut.
In 3.1, I would like to add back the ability to attach other pieces of information to the subscription request, but that will probably require some additional changes to the database schema. I might be able to reuse the Pending database, which at its heart is a rather simple key/value store. Anything we add here would also have to be exposed to the REST API, and I'd rather not let that accept arbitrary parameters.
It's possible that an essay string could be attached to the subscription request. There are implementation details such as making sure the essay gets deleted if the request gets denied or times out, and there are issues of the model as Steve points out. E.g. if a new address is getting subscribed for an existing user, and that user already has an essay, does the new one overwrite the old one, or does it get ignored?
On Jun 13, 2015, at 03:13 PM, Stephen J. Turnbull wrote:
In Mailman 3, there *is* a user model, and you can be a user without subscribing to any lists (eg, a moderator), but every subscription is a relationship between a user and a mailing list.
Right; the model works like this:
Addresses represent an email address. The internal terminology always describes IAddress instances as "address" and string typed email addresses as "email". Addresses have certain properties in addition to the email, as you can see in the IAddress interface.
Users represent people. An IUser can control multiple addresses but an address can only be linked to (zero or) one user. A user can have a "preferred address" which is used in memberships when no explicit address is given. Users can have multiple memberships.
Members represents the relationship between an address or a user (collectively termed "subscriber" internally) and a mailing list. Members also have roles, so this relationship triplet is what defines a membership. E.g. Anne subscribed to the Ant mailing list as a member is a different IMember instance than Anne subscribed to the Ant mailing list as an owner.
A roster is a collection of members, but it's important to remember that there are no roster objects in the database. A roster is a query, so all kinds of rosters can exist. E.g. the roster of all digest members of mailing list Bee, or the roster of all of Bart's memberships in all mailing lists, regardless of role.
This makes it clear that it's possible to subscribe just an address. However, under the hood Mailman provides a dummy user. (This is implied by the comment "Look this up dynamically.")
Right, while the model does support subscribing bare (i.e. unlinked to a user) addresses to mailing lists, this generally isn't exposed externally.
The other important constraint is that users can only be subscribed to mailing lists if they have a preferred address, since ultimately we have to deliver messages to this member, and if we don't know what address to use, we can't send the user messages.
So you should be adding your "essay" attribute to the *users*, not to (list) members.
+1
(IMHO, the term "member" is very confusing, because there's a natural tendency to think of a member as being a person and assuming it has personal attributes, but that's not the case at all in Mailman 2, and in Mailman 3 it might not be the case.)
IMembers (the interface that describes members) indeed doesn't have much personality. The closest thing is perhaps that members can have different preferences than the underlying subscriber (user or address).
The preference system (such as whether a person wants to receive a list copy if they're explicitly CC'd on a message) is based on a hierarchy. Attributes are looked up in this order, with the first one found winning:
- The member's preferences
- The subscribed address's [1] preferences
- The subscribed user's preferences
- The system default preferences
(It's arguable that mailing lists should have preferences, in which case the hierarchy should probably be extended to look up list, followed by domain preferences before the system defaults.)
[1] "The subscribed address" means the IAddress if that was used as the subscriber explicitly, or the IUser's preferred address if the user was subscribed.
I hope that provides some additional useful information. Be sure to read the rest of Steve's response; there's lots of good stuff in there. :)
Cheers, -Barry