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

what are the functions in the software?

what is the need for the new software?

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

Requirements from LiLux

By Iteration

Iteration 0

Code cleanup / preparation:

make it run with error reporting on => DONE

 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 => DONE
back link from editing one payment directly to edit another payment

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) => DONE
- 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". => DONE
- "all users who have paid this year or last year" => DONE
- "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) => DONE

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}{1}

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

tools

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

MembershipManagement

Contents