Brian Carpenter writes:
I think treating all disabled options the same is short-sighted. They are all not the same.
-- Some list members will disable their subscription for good reasons and will be really upset if a List Owner renables it through ignorance. So it is important to know a disable member is done by the member itself.
This is true in principle, but (1) I don't think that the user cares; if they're looking at it, they know whether they want enabled or disabled, how it got that way doesn't matter to them, and (2) I can't see why an admin would disable delivery except on request from a user, so I can't see why an admin would reenable except on request from a user. The only case I can see would be a mass reenabling, but that's not going to happen in the future (I hope).
-- Some mailing lists will have multiple list owners managing them. So it is important for one List Owner to know when a subscription has been disabled by the actions of another List Owner.
I don't see why, see above.
-- A List Owner may not know that some of his List Members are bouncing messages for various reasons, so reviewing their Membership roster, they see that they have some list members disabled due to bounces and can then address those particular problematic members.
This query is an important use case. But it's the only one, I think, unless you really have List Owners arbitrarily disabling members' subscriptions. And if you're thinking about reenabling from that page, I think you need a lot more information. For example, if the admin disabled, you need to know if that was a user request or something else (what?). If bounce disabled, you want to know what the bounce was ("no such mailbox"? probably not a good candidate for reenabling), and when (5 minutes ago? ditto). I guess you could just reenable and see what happens, but that could be risky (eg, sending mail to non-existent users is frowned upon by some providers).
@Abhilash, I highly recommend that you contact me off list about getting access to Affinity so you can see what I am talking about. I would love to show you what I have done for Member Management. I offered the same to Steve but he never was interested in taking a look.
It's not that I lack interest, it's that life got in the way. Unfortunately, until I get enough time (man-weeks, I've never worked on Postorius and very little in Django) to work on Postorius, or somebody else starts to do it, a look at Affinity is low priority. Also, it's pretty clear that a quick look isn't going to be very helpful. The Mailman developers know what Mailman 2 looks like. I think the benefits to a hands-on admin are pretty obvious vs the current Postorius, as are Web 2.0 improvments like sorting on the options. The more subtle improvements you've made are going to require a guided tour and/or some study to identify and understand.
Aside: I have to assume that Postorius is aimed at the kind of subscriber that most of us are, and that list administration was something of an afterthought, and assumed to be mostly hands-off. That's the only rationale I can come up with for the design where list admins need to go to the individual pages to see user options -- it was easier to reuse the user option page and just give the admin permission to access and change it, than to provide a (sortable) list with user details.
Steve