[Mailman-developers] administrative unsubscribing

[Scott]

OK, i'll get started on this stuff next week. confirmation of
subscription requests (allowing forwarding addresses) and an
administrator-only accessed list of subscribers in a table with check
buttons to change their options/unsubscribe them.

Scott

On Sat, Apr 11, 1998 at 01:48:00PM -0400, Ken Manheimer wrote:
| On Sat, 11 Apr 1998, Scott wrote:
| 
| > it seems to me like list admins need a more efficient way to
| > (mass-)unsubscribe members than going through them one at a time the
| > same way that a list member would unsubscribe them.
| 
| This is something i've also had in mind.
| 
| > some ideas for the interface are:
| > 
| > have the mass subscibe box simply full of a list of all subscribers
| > and be able to edit it directly.
| 
| And do some kind of differencing approach, where members that you
| deleted from the list are deleted, and members that you added are added?
| My thoughts have been tending to the next option...
| 
| (I should note that there's another mechanism for doing mass
| subscriptions which i came to rely on for transferring over my existing
| lists - mailman/bin/populate_new_list turns out to work better for me. 
| In either case, you have to be careful to clean out extra stuff from the
| entries - you can't add "klm@python.org (ken manheimer)", for instance.) 
| 
| > under member management administrative interface, list all the members
| > with a checkbox allowing the adminstrator to unsubcribe people one
| > click at a time.  
| 
| I would have a table with an entry for each member, including their
| address and some check buttons, one to disable delivery, one to
| hide/unhide them, and one to unsubscribe them completely.
| 
| There's one nuance that i think should be accounted for as well, which
| makes the setup slightly more elaborate than just that.  I think this
| interface *should* include the members that have set the concealment
| option for their subscription.  However, that means that this interface,
| itself, should be accessed indirectly from the membership management
| page, via something that requires the administrator password.
| Otherwise, non-administrators could visit the admin pages and get to see
| the concealed folks...
| 
| This reminds me of a somewhat related area that really needs work - the
| subscription mechanisms are too basic, at the moment.  There are two
| missing features - actual confirmation of subscription requests
| (currently that's finagled around), and subscription of forwarding
| addresses.  Let me explain...
| 
| I've had several requests from subscribers to be able to change their
| subscription address.  Makes sense to me, but it so happens that the
| current mechanisms for preventing mischievous third-party subscriptions
| are not up to this.
| 
| New web-based subscriptions addresses are "confirmed" by prompting an
| email subscription sent from the subscription address.  Well, that's not
| really confirmation - the web-based subscription attempt isn't recorded
| or anything, it just prompts the helpful message desribing how to
| subscribe, basically.  Well, i don't think we can use the same trick for
| subscription address changes, because the old address needs to be
| removed, as well as adding the new one.  And we can't rely on the
| password for the old address because that doesn't vouch for the
| authority over creation of the new address - ie, someone could subscribe
| at their real address in order to get a password that would allow them
| to subscribe an arbitrary address of their choice.  No good.
| 
| In particular, there is no confirmation tracking done - no database of
| requests to be resolved against confirmations.  We would need something
| like that to do the subscription transfers, i think.  Or at least, i
| think that would be the right way to do it, particularly since such a
| mechanism would enable the other big, lacking subscription feature - the
| ability to subscribe a forwarding address.  Ie, some people have a
| forwarding address at acm.org, but no actual logins there.  They would
| like to be able to subscribe that address, but the current mechanism
| doesn't allow it - it is constrained to the sender/from fields, because
| there is no actual confirmation going on, just identification.
| 
| Anyway, these are some issues i'm hoping to tackle and or yield to
| others...
| 
| > are there any other ideas for how to do this?  if there is a consensus
| > on whether this feature should be added and what the interface should
| > look like, i'll add it to my list of things to implement and get
| > startted next week.
| 
| Cool - the membership management stuff is one of the things i had on my
| list!
| 
| Ken
|