#42: Integration of CMFMember into Plone

Contents

1. Motivation
2. Proposal
3. Implementation

Proposed by

rafrombrc

Proposal type

Architecture

State

rejected

Motivation

Plone's current MemberData implementation is rather cumbersome:

• Any modifications to the MemberData properties requires independent modification of the data set and of all related interfaces and validation machinery (join_form, personalize_form, personalize, related validators, etc).
• There are no hooks provided for sophisticated indexing and searching of Member-related data.
• There are limited hooks provided for customizing site-wide Member management policies.
• Searching for members based on their member data is difficult; it's based on the hardcoded and very inefficient code that exists in MembershipTool.searchForMembers.

CMFMember solves these problems:

• The interface and validation behaviour is controlled by the Archetypes schema and validation chain mechanisms. This provides for centralized management of this behaviour without the need to maintain separate-but-related interface and validation code by hand.
• CMFMember provides a member_catalog, and makes it easy to specify custom indexes using the regular indexing specification support within Archetypes schema definitions. The member_catalog also supports the use of add-on indexing products (e.g. TextIndexNG).
• Since Member objects are full content objects, they are connected to workflows. Workflows provide enough flexibility to allow for complicated member management interactions.
• CMFMember provides a member_catalog which indexes arbitrary member data points, allows sophisticated searching, and returns results quickly even when there are many thousands of member objects

Proposal

This PLIP proposes to replace Plone's default Member and MemberData management mechanisms with CMFMember, a product that implements Member objects as Archetypes content types.

Implementation

The CMFMember product, available from the Collective project on sourceforge.net, is already implemented and works nearly seamlessly as a drop-in replacement for the default Plone member management infrastructure. There is a control_tool that is installed w/ the CMFMember product that handles member and member data migration; this works in an identical fashion to Plone's migration tool. There are almost certainly a few more issues that have not yet surfaced w/ regard to CMFMember's interactions w/ the rest of Plone, but we are working to find these issues and resolve them.

One particularly challenging migration issue is that of dealing with sites that have custom properties defined in the MemberDataTool. CMFMember includes a rudimentary conversion engine that generates an Archetypes schema from default Zope properties. This could certainly use some refining, however, and folks who upgrade to a CMFMember-based Plone will need to take special care to make backups and to check to make sure that all custom member data was migrated successfully.