CMFMember is a replacement for portal_memberdata that provides TTP
(Through-The-Plone) member management. Members are ordinary Archetypes
(AT) objects that are controlled by workflow.  Member data can be
expanded and configured via an AT schema (or via subclassing). For
more about the goals of the project, please see GOALS.txt.


REQUIREMENTS:

    - Archetypes-1.3.2-final (or greater) bundle

    - Plone-2.0.5 (or greater)

      NOTE: If you are running Plone 2.0.5 you will need to add
            the 'cmfmember_plone2_0' skin directory into your
            skins path above the other CMFMember-related skins.
            This is done via the ZMI, on the Properties tab of the
            skins tool (portal_skins).

            If you upgrade to Plone 2.1 at a later time, you will
            want to remove 'cmfmember_plone2_0' from you skins
            path.


OPTIONAL REQUIREMENTS:

    - ATSchemaEditorNG-0.3.2 (for TTW schema editing, see below)
      !!REQUIRED FOR CUSTOM MEMBER PROPERTY MIGRATION!!


WARNINGS:

    Before you get all excited about upgrading, please be aware of the
    following "gotchas" regarding CMFMember:

    - There is NO reverse migration, meaning once you migrate your
      existing Members to CMFMember types, there is no mechanism
      provided for going back to "the way things were".  It is HIGHLY
      RECOMMENDED that you back up your entire Plone site before
      proceeding with migration.

    - We have provided a mechanism for migrating your custom member
      data (i.e. properties defined in the memberdata tool) over to an
      AT schema for your convenience.  This REQUIRES ATSchemaEditorNG
      version 0.3.0 or greater.  This has NOT been heavily tested.  We
      STRONGLY recommend you check to make sure all of your fields
      were migrated properly.

    - If you upgrade Archetypes out from under CMFMember, all of the
      catalog associations may disappear.  (To see these, go to the
      archetype_tool, click the Catalog Tab and you'll see all of the
      catalog associations. The way to avoid this is to reinstall
      CMFMember after getting Archetypes to where you want it.  (See
      Requirements section)

    - If you change the workflow that is associated with your Member
      type, your existing users will be set to the initial (default)
      state of your new workflow.  This is because the information
      about the workflow state is stored in the workflow itself.
      A recommended workaround is to write a quick script that
      captures the existing states, then, after your workflow change,
      sets the Members to whatever state you map them to::

       wf_map = {
                 'public':'public',
                 'private':'secret',
                 'new':'unregistered',
                }

       user ID:   Old State:   New State:
       ========   ==========   ==================
       user_1     public       wf_map['public']
       user_2     private      wf_map['private']
       user_3     new          wf_map['new']

      or something like that...


INSTALLATION:

    1. Put CMFMember (and the Requirements) in your Zope Products directory.

    1a. Run the test suite.  This will require ZopeTestCase available from
        Stefan Holek, whose testing technique is unstoppable:

        http://zope.org/Members/shh/ZopeTestCase

        While you're at it, we suggest you check out his band, EPY:

        http://epy.co.at/

    2. Restart Zope.

    4. Install CMFMember into your Plone site using
       CMFQuickInstaller. (In Plone, select "plone setup", click on
       "Add/Remove Products" and install CMFMember.)  You can also use
       the portal_quickinstaller tool from the ZMI to install the
       Product.

    5. Click on the CMFMember entry in in the navigation portlet. (The
       entry probably says something like "CMFMember out of date".)
       You can also use the cmfmember_control tool from the ZMI for this.

    6. (SEE WARNING ABOVE) Click the "migrations" tab and migrate.


WORKFLOWS:

    CMFMember comes with two workflows by default:

        - member_auto_workflow (default)

          This workflow works almost the same as the normal Plone
          registration -- the member is registered upon submission
          of the registration form and can immediately log into the
          site.

        - member_approval_workflow

          The approval workflow forces the registration into an approval
          process, much like the publication workflow for regular content.
          The pending member cannot log in until a site manager approves
          the registration.

    Feel free to build a custom workflow and associate it to the Member
    Type! This is why we built this thing. ;)  If you do, be sure to review
    the warning section above.


EXTENDING MEMBERS:

    CMFMember allows you to customize the member data. You can customize
    the data either using a TTW (through-the-web) schema editor, or by
    creating an Archetypes module that subclasses CMFMember.Member.

    Optional Field Attributes

      CMFMember adds an optional attribute to the Archetypes Field
      schema. This attribute allows CMFMember to present the member edit
      form differently, depending on whether the register action has run yet.

      **regfield** -- The 'regfield' attribute is used to mark fields that
      should appear on the registration form. Fields must have
      'regfield=1' in order to appear on the form.

      Note that if a field is marked as required ('required=1') but not
      marked as a regfield, it will not appear on the registration form.
      In this case, validation will fail and the workflow will not trigger
      the next state.

    TTW Schema Editing

      If you have ATSchemaEditorNG installed, it is possible to manage
      your member schema using a nice web interface.  Note, however,
      that this feature is new and relatively untested, and, as such,
      it is *not* activated by default.  In order to turn on TTW
      schema management, you must set 'USE_SCHEMA_EDITOR = True' in
      config.py.

      NOTE: If you have already installed and migrated to CMFMember
      w/o enabling schema editor support, and then you enable schema
      editing at a later time, you will need to take the following
      steps to fully activate the schema editing support:

      - Back up your ZODB.

      - Make sure the ATSchemaEditorNG product is installed into your
        Plone site (via CMFQuickInstaller).

      - Visit the 'migrations' configuration screen and run a 'Forced
        migration', choosing '1.0.1' as the version to be upgrading
        from.

      Once schema editing support has been enabled, you should be able
      to access the interface via a 'Schema editor' link in the
      CMFMember configuration portlet, available in the 'site setup'
      area of your Plone site.  Please note that once you have used
      the schema editor to customize your member data, then disabling
      the schema editor support may cause breakage.


MAILING LIST:

    Interested Users and Developers are welcome to join the
    collective-cmfmember@lists.sourceforge.net mailing list, hosted on
    SourceForge as part of the Collective project:

    http://lists.sourceforge.net/lists/listinfo/collective-cmfmember


BUGS:

    Please report bugs (which are different from feature requests) to
    the following collector:

    http://plone.org/development/teams/developer/groups/issues


TUTORIAL:

    The Samplex (SAMPLe EXtranet) product that is in the Collective
    repository on svn.plone.org provides code and extensive
    documentation illustrating how to create a custom member type
    based on CMFMember's default type.  (Also requires TeamSpace
    product.)  This is available from the following URL:

    https://svn.plone.org/svn/collective/Samplex/trunk/


FEATURE REQUESTS:

    In the spirit of Open Source, we suggest you write your new features
    to satisfy your particular Use Case yourself!  Cut a branch, work on
    your changes; we'll review them and merge them in if appropriate.

    One thing we ask is that if you plan on writing new features, you
    keep the entire community in mind, write your features as options,
    and use "best practices" coding techniques.  We also ask that you
    write tests for your code before it will be considered.  Open
    communication is key!  Join the #cmfmember channel on IRC
    (irc.freenode.net), ask questions, let people know what direction
    you want to take and you'll find friendly helpful people.


Thanks for using CMFMember, built with beer!
