[Mailman-Users] add_members

[Mark Sapiro]

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 at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan