Difference between revisions of "MembershipManagement"

From LiluxWiki
Jump to navigationJump to search
(Error reporting done, even with DEPRECATED)
 
(23 intermediate revisions by 9 users not shown)
Line 10: Line 10:
 
  * API to member list to include other tools like libraries ...
 
  * API to member list to include other tools like libraries ...
 
  * Integration with mediawiki/joomla ...
 
  * Integration with mediawiki/joomla ...
−
 
−
== Requirements from Hackerspace ==
 
−
https://www.hackerspace.lu/wiki/Membership_Management_Tool#Requirements
 
  
 
== Task List ==
 
== Task List ==
  
−
* setup cvs  - ThierryCoutelier
+
* setup cvs  (- ThierryCoutelier) or use github (http://github.com/kwisatz/ArchReactorOS)
 
* prepare initial design on wiki
 
* prepare initial design on wiki
 
* setup test web page
 
* setup test web page
−
* Add project to TRAC: (https://www.hackerspace.lu/trac) - David Raison
 
  
−
=== See also ===
+
== 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 ===
 +
* 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
 
* https://www.hackerspace.lu/wiki/Membership_Management_Tool
−
* http://archreactor.org/wiki/index.php/AROS
 
  
−
== suggestion: use LDAP ==
+
 
 +
== suggestions: ==
 +
=== LDAP ===
 
* user data, can be standard schema + whatever we may additionally need
 
* 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, ...
 
* would facilitate SSO functionalities, incl. integration with misc tools such as CMS, Wiki, shell access, ...

Latest revision as of 10:47, 14 July 2012

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

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


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
Retrieved from "https://www.lilux.lu//mediawiki/?title=MembershipManagement&oldid=980"