Revision as of 13:53, 17 August 2010

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
prepare initial design on wiki
setup test web page
Add project to TRAC: (https://www.hackerspace.lu/trac) - David Raison

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
assigne members to a group / to a activity

Requirements from Hackerspace

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

Requirements from LiLux

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

@@ Line 13: / Line 13: @@
 == Task List ==
-* setup cvs  (- ThierryCoutelier) or use github (http://github.com/kwisatz/ArchReactorOS)
+* setup cvs  - ThierryCoutelier
 * prepare initial design on wiki
 * setup test web page
+* Add project to TRAC: (https://www.hackerspace.lu/trac) - David Raison
 == definitions ==
@@ Line 43: / Line 44: @@
 === what is the need for the new software? ===
-=== which are the fonctions needed? ===
+=== which are the functions needed? ===
 * list printing of groups / activities / ...
 * printing of membership cards
@@ Line 52: / Line 53: @@
 === general requirements ===
 * manage membership easily
-* assign members to a group / to a activity
+* assigne 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
-=== 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 ==
@@ Line 178: / Line 82: @@
 * tutorial available for instance from LinuxDays 2003, server tutorial
 * LDAP can be frontend to SQL database
+=== .====

Difference between revisions of "MembershipManagement"