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
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
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)
- 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
- ...
- 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
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