View source for 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) '''=> 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 ===
* http://archreactor.org/wiki/index.php/AROS
* [http://membership.scouthub.org/ MemberShip]
* [http://www.scoutreg.org/ scoutreg]
* [http://code.labitat.dk/index.php/p/member-dev/ member-dev]
* [http://webcomite.com/default_fr.htm webcomite]
* [http://association-1901.fr/ association-1901]
* [http://http://membership-software.org/ membership-software.org]

=== tools ===
* [http://www.nubuilder.com nuBuilder]
* [http://limbas.org 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