MembershipManagement

Membership Management

Kick off Meeting

Wednesday 27/01/2010

Points discussed:

* Separate members for each club (a club should not know if a user is in a different club)
* Use a pseudo will be used as key for the user.
* API to member list to include other tools like libraries ...
* Integration with mediawiki/joomla ...

Task List

• setup cvs (- ThierryCoutelier) or use github (http://github.com/kwisatz/ArchReactorOS)
• prepare initial design on wiki
• setup test web page

definitions

association

an organisation who will use the application: LiLux, HackerSpace, Scouts, …

member

a member is a person listed in the membership software

group

a group is an combination of diffrent members from the membership software a group can be made of a parent-group and/or can be in a child-group

parent-group --- group --- child-group --- child2-group

activity

an activity can be e meeting / camp / .... The activity is created by an operator but the registered members can subscribe to the activity by answering a mail or completing a web form

Analysis

what do we have as software?

• a php script

which are the functions needed?

• list printing of groups / activities / ...
• printing of membership cards
• use mail adresses in mailman
• unlimited creation for groups / activities

Requirements

general requirements

• manage membership easily
• assign members to a group / to a activity

Requirements from Hackerspace

https://www.hackerspace.lu/wiki/Membership_Management_Tool#Requirements

By Iteration

Iteration 0

Code cleanup / preparation:

• make it run with error reporting on

 error_reporting (E_ERROR | E_WARNING | E_PARSE | E_NOTICE);

• put as many items as possible into functions and/or objects
• set it up as SSL

Iteration 1

Usability improvements for admin

• In "View entries of user DB", provide a checkbox to each entry for easy "mass actions", and a check-all button. The following mass actions will be available:
  • "delete" (with confirmation)
  • "membership card sent"
  • "paid this year"
  • "CSV list of checked users"
  • "Latex mailing include of checked users" (template, see below)
• In the view for individual user
  • provide "Delete this user" button (with confirmation)
  • provide "Paid membership card for this year" button (with some indication whether already set)
  • provide "Membership card sent for this year" button (with some indication whether already set)
• In "Edit payments" provide the option to edit and delete existing payments (for instance, if a typo was made in year)
• Some new views. These views should have same mass actions as "View all entries view" described above
  • "all users who have paid this year, and whose membership card was not yet sent".
  • "all users who have paid this year or last year"
  • "all users who don't have a post address"
  • "all users who never paid"
• The implementation of the views should be modular, so that it easy enough to add some more (function that takes a title and

parts of select statement that choses the users to be displayed).

• Remove "Modify entries", "Edit payments" and "Download CSV list": indeed, these functions are now more easily accessible from the views.
• Sort order of views can be changed (by clicking on the relevant column header)
• Add male/female column (useful for proper "Anrede" in mailings)

Example of Latex mailing template:

 \adrentry{Paul}{Muller}{42, rue de la vallée \\ L-4242 Hannerkléngwäinhäffen}{m}
 \adrentry{Marie}{Gelatine}{19, rue de la forge \\ L-1234 Knapphouschent}{f}

Iteration 2

Access by the user himself to his records

• User can request a password to be sent to him to his e-mail address
  • This can be sent right at registration
  • At a later time, user may request password by pseudo or by e-mail
• User can use this password to view his own record
• User can change his password
• New views (for admin):
  • users with un-confirmed email
  • users with confirmed email
• New fields:
  • Exact date when payment (and extrait number) was received
• Date of payment visible to member himself, extrait number should only be visible for admin
• Support for more than one payment per year
• Management of "in kind" contribution (such as, helping at an event)

Note: Extrait number is useful to more easily help confirm at a later date that we didn't do a mistake.

Iteration 3

LDAP integration

• New users should automatically be created in LDAP
• Admin can "confirm" users, and grant them certain privileges
  • local Unix account
  • mail
  • ...
• Unconfirmed users should not be able to log in, and should not have any other rights on the system.
• New view:
  • Unconfirmed users
  • Confirmed users

Note: confirmation by the admin is something different than confirmation of the e-mail address (which just proves that user can receive e-mail at that address)

Iteration 4

More usability:

• Admin may define new views in GUI (by supplying a title, and part of an SQL statement that selects the wanted users)
• Persistent user sets (after having ticked a number of user, admin may save this as a set for use on a later date)
• Admin may define new output formats (in addition to CSV and Latex mailing list)
• More than one admin
• Admin with read-only (or otherwise restricted) rights
• In case of multiple admins, each admin may chose whether additional views and output formats only apply to him or to all admins as well.

Iteration 5

Multiple clubs:

• Admin of a club may only view his own members
• There is a super admin who sees all clubs/defines new clubs.
• For views and output formats, there are now 3 levels of scope:
  • all admins of all clubs
  • admins of same club
  • only that admin himself

Note: If need arises, we may put this iteration somewhat earlier in the schedule.

Existing software/tools

software

• http://archreactor.org/wiki/index.php/AROS
• MemberShip
• scoutreg
• member-dev
• webcomite
• association-1901
• membership-software.org

tools

• nuBuilder
• Limbas

related sites

• https://www.hackerspace.lu/wiki/Membership_Management_Tool

suggestions:

LDAP

• user data, can be standard schema + whatever we may additionally need
• would facilitate SSO functionalities, incl. integration with misc tools such as CMS, Wiki, shell access, ...
• not complicated to set up and get running
• tutorial available for instance from LinuxDays 2003, server tutorial
• LDAP can be frontend to SQL database