Re: [Mailman-Users] add_members
Mark,
Bingo!
The script from the sourceforge site works fine. Here are the diffs between that version and the version that Apple is providing. Note the change of address of Foundation and the ill-fated option in the Apple-supplied version to disable mail for the new subscriber. (< is official version, > is Apple's version).
A bit of nosing around on the sourceforge site shows that the address was changed on the main cvs branch from version 2.16 to version 2.17 on 8/17/05. The copyright notice on both 2.17 and Apple's version are both 1998-2003. None of the versions 2003 and later has Apple's changes, as you also noted.
So Apple's version does, indeed, appear to be an Apple hack gone awry. I suppose it could be fixed by extracting the address before sending the member to setDeliveryStatus, but I'll refrain from that.
Thank you for the sourceforge reference. It will simplify my scripts.
Allan
The differences:
17c17 < # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. 54a55,58 --enable-mail=
-e Enable user mail deilvery options.
79a84
from Mailman import MemberAdaptor 127c132 < def addall(mlist, members, digest, ack, outfp):
def addall(mlist, members, digest, ack, outfp, enable): 137a143,146 if enable == 1: mlist.setDeliveryStatus(member, MemberAdaptor.ENABLED) else: mlist.setDeliveryStatus(member, MemberAdaptor.BYADMIN) 146a156,160 if enable == 1: mlist.setDeliveryStatus(member, MemberAdaptor.ENABLED) else: mlist.setDeliveryStatus(member, MemberAdaptor.BYADMIN)
149d162 < 153c166 < 'a:n:r:d:w:h',
'a:n:r:e:d:w:h',
154a168
'enable-mail=',
168a183
enable_mail = 1
184a200,206
elif opt in ('-e', '--enable-mail'): if arg.lower()[0] == 'y': enable_mail = 1 elif arg.lower()[0] == 'n': enable_mail = 0 else: usage(1, _('Bad argument to -3/--enable-mail: %(arg)s'))
235c257 < addall(mlist, nmembers, 0, send_welcome_msg, s)
addall(mlist, nmembers, 0, send_welcome_msg, s, enable_mail)
238c260 < addall(mlist, dmembers, 1, send_welcome_msg, s)
addall(mlist, dmembers, 1, send_welcome_msg, s, enable_mail)
256d277 <
At 22:20 -0800 2/27/06, Mark Sapiro wrote:
Allan Hansen wrote:
I'm starting with an empty list called Test and a file, Long, with a subscriber (me) in long format, and another file, Short, with a subscriber (me) in short format:
// Empty list $/usr/share/mailman/bin/list_members -f Test <nothing>
// The files Long and Short $cat Long Allan Hansen hansen@rc.org
$cat Short hansen@rc.org
// Here's the traceback from add_members: $add_members -r Long Test Traceback (most recent call last): File "/usr/share/mailman/bin/add_members", line 277, in ? main() File "/usr/share/mailman/bin/add_members", line 257, in main addall(mlist, nmembers, 0, send_welcome_msg, s, enable_mail) File "/usr/share/mailman/bin/add_members", line 157, in addall mlist.setDeliveryStatus(member, MemberAdaptor.ENABLED) File "/usr/share/mailman/Mailman/OldStyleMemberships.py", line 338, in setDeliveryStatus self.__assertIsMember(member) File "/usr/share/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member Mailman.Errors.NotAMemberError: Allan Hansen hansen@rc.org
This is apparently some Apple modified add_members script. The line numbers don't correlate with any distributed Mailman 2.1.x, and the standard script does not call the setDeliveryStatus() method at all.
<snip> > >// Now, let's try removing same. We have a problem: >$/usr/share/mailman/bin/remove_members -f Long Test >No such member: Allan Hansen <hansen@rc.org>
Yes, I mentioned this previously. remove_members does not accept the 'long' format, but then if you're removing a member, you probably don't care about the 'name'.
The above shows that 'add_members' and 'remove_members' don't understand the long format that is readily accepted by 'sync_members' and output by 'list_members'.
Well, my add_members does. I think Apple broke yours. You might try getting a recent add_members from http://cvs.sourceforge.net/viewcvs.py/mailman/mailman/bin/add_members, and see if that works for you.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
--
| Allan Hansen, Ph.D. | | P.O. Box 2423, Cypress, CA 90630, U.S.A. | | | | Work: Home: | | Phone: +1-714/952-6015 +1-714/875-8870 | | Fax: +1-714/952-6746 | | Email: allan.hansen@ugs.com hansen@rc.org | | WWW: http://www.ugs.com http://www.rc.org/ | | | |_Anything is possible with the right tools and right information_|
Allan Hansen wrote:
So Apple's version does, indeed, appear to be an Apple hack gone awry. I suppose it could be fixed by extracting the address before sending the member to setDeliveryStatus, but I'll refrain from that.
Yes, but why? See below for fix, but the hack adds the --enabled option to set the added members delivery status to enabled or disabled by admin. If the member is truly added, delivery is already enabled, so this is unnecessary. I suppose if you wanted to use this to add members with delivery disabled, it might be useful. It can also be used to set delivery status for existing members...
The differences: <snip> 137a143,146
if enable == 1: mlist.setDeliveryStatus(member, MemberAdaptor.ENABLED) else: mlist.setDeliveryStatus(member, MemberAdaptor.BYADMIN)
146a156,160
if enable == 1: mlist.setDeliveryStatus(member, MemberAdaptor.ENABLED) else: mlist.setDeliveryStatus(member, MemberAdaptor.BYADMIN)
In all the setDeliveryStatus calls above, 'member' should be replaced by 'userdesc.address' to allow input with names.
<snip> >184a200,206 >> elif opt in ('-e', '--enable-mail'): >> if arg.lower()[0] == 'y': >> enable_mail = 1 >> elif arg.lower()[0] == 'n': >> enable_mail = 0 >> else: >> usage(1, _('Bad argument to -3/--enable-mail: %(arg)s'))
'-3' above should be '-e'.
And, I wonder if Apple really updated the translations to include that message?
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Allan Hansen wrote:
So Apple's version does, indeed, appear to be an Apple hack gone awry. I suppose it could be fixed by extracting the address before sending the member to setDeliveryStatus, but I'll refrain from that.
Yes, but why?
Upon rereading my post, I see the above "but why" doesn't say what I meant. It appears that I'm saying "but why refrain from fixing the hack?" This is definitely not what I meant to say.
I meant to say "but why fix it?", just the opposite of how it comes out. I did indicate how you could fix it, but I also tried to say that I didn't see a real need for the botched option in the first place.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Allan Hansen
-
Mark Sapiro