Issues with users subscribed via their preferred address
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| GNU Mailman |
Confirmed
|
Low
|
Unassigned | ||
Bug Description
You can subscribe an address to a mailing list, and you can subscribe a user to a mailing list, if the user has a preferred address. There are two problems with this.
* You can actually end up getting doubly subscribed (i.e. same address with the same role). Normally, the subscription mechanism prevents you from subscribing the same address with the same role more than once, or the same user with the same role more than once. However, if you subscribe once by the address, and once by the user whose preferred address is that same address, the double subscription occurs.
* The Member repr() doesn't distinguish between a member that's subscribed via explicit address, and one that's subscribed via preferred address. This means that the above will appear as a double address subscription, when it's really not.
Are these substantial problems that need to be fixed? Almost certainly the second one does, but I haven't come up with an elegant repr() for the case of a user subscribed with their preferred address.
| Barry Warsaw (barry) wrote | #1 |
| Abhilash Raj (raj-abhilash1) wrote | #2 |
Some thoughts:
First, this should not cause problems with multiple deliveries since MM creates a set of recipient addresses for the message, which filters out duplicates.
As for Member.__repr__() perhaps something like this (untested):
def __repr__(self):
if self._address is None:
else:
return '<Member: {0} on {1} as {2}>'.format(
Can you try that and see what you think?
As for #1, I'm not sure it's a problem given the above, but if it does prove to be so, I can think of a few alternatives. Maybe the user should be disallowed from subscribing when an address they control is already subscribed with the same role. It's theoretically possible that an address could come under the control of the user after the fact, and that would be difficult to catch.
Another possibility would be to convert the existing address-based subscription to a user-based subscription, but that might clobber the address that they actually want to get delivery on. E.g. they're subscribed with <email address hidden> but their preferred is <email address hidden>.
Any other ideas? I think if this is a problem, in the face of ambiguity, refuse to guess (i.e. disallow those double subscriptions).