[Mailman-Developers] Exporting member info (including options)

[Mark Sapiro]

Aaron Kreider wrote;

>  I'm figuring out where to get the information from the config.pck 
>(pickle file) for each list to populate the MySQL table.
>
>It seems like the MySQL format is extracting some of its fields from the 
>user_options fields, is this true?


user_options is used by OldStyleMemberships.py to store the user's
options defined by the bit definitions (from Defaults.py)

# Bitfield for user options.  See DEFAULT_NEW_MEMBER_OPTIONS above to
set
# defaults for all new lists.
Digests             = 0 # handled by other mechanism, doesn't need a
flag.
DisableDelivery     = 1 # Obsolete; use set/getDeliveryStatus()
DontReceiveOwnPosts = 2 # Non-digesters only
AcknowledgePosts    = 4
DisableMime         = 8 # Digesters only
ConcealSubscription = 16
SuppressPasswordReminder = 32
ReceiveNonmatchingTopics = 64
Moderate = 128
DontReceiveDuplicates = 256

but these options are accessed and set via the list
(set|get)MemberOption() methods defined by the MemberAdaptor and can
be stored internally by the MemberAdaptor in any way it wants. There
is no requirement that the MemberAdaptor store an integer field with
value = the sum of the option bits, however, if it doesn't, it
complicates the setting of member options from new_member_options in
the addNewMember() method.


>If this is true, it is confusing because several of the user_options are 
>listed in their own field AND in the user_options field.


Examination of
<http://trac.rezo.net/trac/rezo/browser/Mailman/MySQLMemberAdaptor/MysqlMemberships.py>
(is that what you're using?) shows that it stores and uses
user_options in the same way as OldStyleMermberships.py. hide, ack,
not_metoo and plain are defined fields in the MySQL database table,
but are otherwise unreferenced by MysqlMemberships.py.


>***MySQL field -- Pickle Source***
>address -- members object
>hide -- useroptions (16)
>nomail -- useroptions (128) - am I right about this?

No. nomail is not a user_options bit although it used to be the
DisableDelivery bit.

The 128 bit is Moderate.


>ack -- useroptions (4)
>not_metoo -- useroptions (2)
>digest -- digest_members object
>plain -- useroptions (8)
>password -- password object
>lang -- language object
>name -- usernames object
>one_last_digest -- one_last_digest object.  I guess the email would be 
>listed here if I had any people using this setting.

This setting is used when a member switches from digest to non-digest
if there are digest messages pending at the time of the switch. It is
effectively unused by MysqlMemberships.py.

Whatever you put in the MySQL one_last_digest field is irrelevant
because there is no MemberAdaptor method to query it or return a list
of members for which one_last_digest is true. The code in ToDigest.py
is

    drecips = mlist.getDigestMemberKeys() + mlist.one_last_digest.keys()

so unless the MemberAdaptor maintains the list attribute
one_last_digest dictionary, it doesn't work anyway. And,
MysqlMemberships.py doesn't even maintain the MySQL database field.


>user_options -- user_options
>delivery_status -- This seems to be a combination of user_options 
>settings "1" and "2",  am I right?

delivery_status is no longer a user_options bit. It is a separate
entity maintained with (set|get)DeliveryStatus() as a tuple with
possible values

# 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

along with a timestamp.


>topics_userinterest -- there is a topics_userinterest object which I'm 
>not using.
>delivery_status_timestamp - I don't see this listed in config.pck.  
>Where is this?  I guess I'm not too worried about it as it seems like a 
>temporary thing to do with bounces.


It is used for the getDeliveryStatusChangeTime() method. With
OldStyleMemberships.py, delivery_status is a dictionary keyed by
member with values of tuples consisting of the status (0 - 4 as above)
and the time it was set.


I think you would be much better off looking at the various get and set
methods in OldStyleMemberships.py and comparing them to the ones
defined in MysqlMemberships.py to see what MySQL database items
correspond to the list member attributes stored by
OldStyleMemberships.py.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan