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.
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.
under member management administrative interface, list all the members with a checkbox allowing the adminstrator to unsubcribe people one click at a time.
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.
scott
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
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
|
participants (2)
-
Ken Manheimer
-
Scott