User export

[ejucovy]

Remaining to do:

• site role (admin/member)
• confirmation code for unconfirmed members? maybe?
• last login date

[ejucovy]

For simplicity I think that we should try to avoid data-overlaps with project exports. So any member-related data which is exported with a project should not be exported with the member. This includes project memberships and roles, mailing list subscriptions and roles, etc.

[ejucovy]

Site roles will, however, need to be exported; as will account confirmation status. (Unless we just choose to discard unconfirmed members and not provide export/import of them.)

[d-mo]

We should be able to use Izhar's script to export the user data and hashed passwords in csv:
http://blog.kagesenshi.org/2008/05/exporting-plone30-memberdata-and.html

[ejucovy]

Trying this out by hand .. the passwdlist OOBTree (self.acl_users.source_users._user_passwords) appears to be empty. :(

However, with a member object in hand, a simple member.password returns an algo:hash password string like hmac_sha:XXXXXXX -- though on some member objects it appears to be empty.

Looking through the Products.remember implementation of member._setPassword it looks like we can then simply take that string and set it on the member object like so: member.getField('password').set(member, algo_hash_password_string)

Still need to investigate:

1. If we retrieve those strings and then re-set them, will the password remain intact? (Should be easy to test e.g. by creating a new member object, setting its password field by hand to the password string from a user account whose account we know, and then testing TTW login.)
2. Why do some member objects have a null value for the password field?

[ejucovy]

If we retrieve those strings and then re-set them, will the password remain intact?

This seems to be true. The only catch is that each remember user object maintains its own stored "hmac_key" (in a Products.remember.content.password_hashers.HMACHash object's storage['hmac_key']) which is used in generating a hash of the provided credentials to compare against the stored hash. Each user's "hmac_key" is a simple repr of the member object -- e.g. "<OpenMember at ejucovy>". When doing a simple export/import these hmac_keys should be set correctly, as long as we don't modify any user IDs.

[ejucovy]

Why do some member objects have a null value for the password field?

Actually this seems to have been an error on my part -- looking through a CSV dump I'm not seeing any missing values offhand.

[ejucovy]

Meanwhile, here's how we can determine if a user account is pending or confirmed:

from opencore.member.workflow import MemberWorkflowHandler
MemberWorkflowHandler(member_object).is_unconfirmed()

...will return either True (if the member is pending) or False (if the member is confirmed)

[ejucovy]

Also we need to get user portraits -- we can write them to a folder in a zip file and then put a reference to each one in the appropriate line of the CSV.

[ejucovy]

Initial script added: 986aebb

Still needs:

• member creation date
• site role (admin/member)
• portrait url
• actual portraits written to a tempdir
• the tempdir and the csv written to a ZIP file
• confirmation code for unconfirmed members? maybe?

[ejucovy]

Image files are now being written to a tempdir, and referenced in the CSV, in f8f974f

[ejucovy]

Creation date: b9ee8f8

[ejucovy]

Updated issue with current to-dos. Original issue content:

First we need to spec out what is involved in user export -- what content and data must be attached to a user export, and how to ensure that the export is lossless.

I believe the biggest questions here are:

1. Can we export the user's hashed password in a way that keeps his password intact during a subsequent reimport (assuming it's reimported into an opencore instance with the same secret key)
2. Can we export the user's creation date in a way that can be reimported (less important, but it would be nice to preserve this)

[ejucovy]

Remaining work: #29, #30, #31