Thank you for developing this adaptor! So far it's working
well with the limited testing I've done.
There seems to be a minor bug in the addNewMember method of
this adaptor (version 1.61).
At lines 579-584, there are SQL statements which add a new
row in the MySQL database for a new member. In those
statements, the column 'delivery_status' is given the value
of MemberAdaptor.UNKNOWN. MemberAdaptor.py defines:
# Delivery statuses
ENABLED = 0 # enabled
UNKNOWN = 1 # legacy disabled
BYUSER = 2 # disabled by user choice
BYADMIN = 3 # disabled by admin choice
BYBOUNCE = 4 # disabled by bounces
So, it appears that the SQL statements should be changed to
use the value of MemberAdaptor.ENABLED instead of
MemberAdaptor.UNKNOWN (which is "legacy disabled").
Making this change prevents "nomail [reason]" ? from being
set in the user's options for new members (as seen in the
web interface). This was tested with Mailman 2.1.6.
Logged In: YES
user_id=1175103
Thank you for developing this adaptor! So far it's working
well with the limited testing I've done.
There seems to be a minor bug in the addNewMember method of
this adaptor (version 1.61).
At lines 579-584, there are SQL statements which add a new UNKNOWN. MemberAdaptor.py defines:
row in the MySQL database for a new member. In those
statements, the column 'delivery_status' is given the value
of MemberAdaptor.
# Delivery statuses
ENABLED = 0 # enabled
UNKNOWN = 1 # legacy disabled
BYUSER = 2 # disabled by user choice
BYADMIN = 3 # disabled by admin choice
BYBOUNCE = 4 # disabled by bounces
So, it appears that the SQL statements should be changed to ENABLED instead of UNKNOWN (which is "legacy disabled").
use the value of MemberAdaptor.
MemberAdaptor.
Making this change prevents "nomail [reason]" ? from being
set in the user's options for new members (as seen in the
web interface). This was tested with Mailman 2.1.6.