Attention

This document was written for an unsupported version of Plone, Plone 2.5.x, and was last updated 1630 days ago.

For more information, see the version support policy.

To learn how to upgrade to the current version of Plone, read the upgrade manual.

How do I add my own member properties?

Plone's default member properties cover the basics, but integrators often need to add additional member data specific to their use case.

« Back to Table of Contents

Warning: This item is marked as outdated.

The simplest option is just to use the portal_memberdata tool and manage simple properties, as per this how-to. If all you need is to store a few more fields, that's fine.

If you need to represent members as objects with workflow (e.g. to approve a member before becoming a full member of the site), and very advanced member data (e.g. you need complex validation, or you need to store a lot of other objects attached to the member object) then you have two options:

For Plone 2.1, you can use CMFMember, which has been out there for a very long time, but it also rather big and scary. It works well, but because of the frameworks it had to work with, it's prone to sometimes give you unexpected results.

For Plone 2.5, you can use membrane (lowercase m, in keeping with Zope 3 naming conventions) which is a Zope3-powered solution that uses PAS/PlonePAS (the authentication architecture in Plone 2.5). This is very elegant, and much lighter weight than CMFMember. It does not slot into Plone's member management at all (this is not its purpose), but it does give you a framework to represent users, their properties, their group memberships etc. in a very flexible way. You can use Membrane (capital M), the original and more Zope2-ish version in Plone 2.1, though you probably need to install PAS and PlonePAS too. At the time of writing, membrane is still in active development, but the version in svn is quite stable and used by several developers.

... which brings us to remember: remember is an effort to build what CMFMember was - a full-on replacement for the standard member management functionality in Plone - on top of membrane. It will provide the same basic member properties, and the same UI for finding, editing, joining etc. By leveraging membrane, it will also be easier to extend for your own use cases. Hence, remember will make sense where you need the power of membrane, but you are only interested in tweaking Plone's default member management.

At the time of writing, remember is not yet released. However, its authors have expressed an interest in providing a migration path from CMFMember to remember eventually.

How do you know which one to use?

Consider an example of a typical organisation, where staff members are users, and they are organised in departments.

In membrane, it would be easy to create two content types representing these: Department and Staff Member. A Department could be made to represent a group, and a Staff Member could be made to represent a user. Beyond that, they could be full Archetypes (or non-Archetypes) content objects, with rich schemata describing departments and their members. A Department would then be a folder that would contain a department's Pages and Files, but also its Staff Members.

The site administrator would then add departments as necessary, and a group would spring into existence for each one. Each staff member inside any department would be a first-level user, with the ability to log in and use the site - all of this without resorting to the low-level/generic member management of Plone's control panel.

In this case, you don't need remember or CMFMember: you need membrane, and the user management story it offers may be more appropriate than the one offered out-of-the-box in Plone.

On the other hand, if you wanted to sign up users via a "join" link like Plone has by default, and manage them all via a control panel applet, but add some custom properties and behaviour, then either stock Plone, CMFMember or (in time) remember will be for you.