https://www.lilux.lu//mediawiki/api.php?action=feedcontributions&user=78.141.149.18&feedformat=atomLiluxWiki - User contributions [en]2024-03-29T10:38:07ZUser contributionsMediaWiki 1.35.6https://www.lilux.lu//mediawiki/?title=MembershipManagement&diff=449MembershipManagement2010-05-31T05:49:20Z<p>78.141.149.18: /* Iteration 1 */</p>
<hr />
<div>= Membership Management =<br />
<br />
== Kick off Meeting ==<br />
<br />
Wednesday 27/01/2010<br />
<br />
Points discussed:<br />
* Separate members for each club (a club should not know if a user is in a different club)<br />
* Use a pseudo will be used as key for the user.<br />
* API to member list to include other tools like libraries ...<br />
* Integration with mediawiki/joomla ...<br />
<br />
== Task List ==<br />
<br />
* setup cvs (- ThierryCoutelier) or use github (http://github.com/kwisatz/ArchReactorOS)<br />
* prepare initial design on wiki<br />
* setup test web page<br />
<br />
== definitions == <br />
=== association ===<br />
an organisation who will use the application: LiLux, HackerSpace, Scouts, …<br />
<br />
=== member ===<br />
a member is a person listed in the membership software<br />
<br />
=== group ===<br />
a group is an combination of diffrent members from the membership software<br />
a group can be made of a parent-group and/or can be in a child-group<br />
<br />
parent-group --- group --- child-group --- child2-group<br />
<br />
=== activity ===<br />
an activity can be e meeting / camp / ....<br />
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<br />
<br />
<br />
== Analysis ==<br />
=== what do we have as software? ===<br />
* a php script<br />
<br />
=== what are the functions in the software? ===<br />
<br />
=== what is the need for the new software? ===<br />
<br />
=== which are the fonctions needed? ===<br />
* list printing of groups / activities / ...<br />
* printing of membership cards<br />
* use mail adresses in mailman<br />
* unlimited creation for groups / activities<br />
<br />
== Requirements ==<br />
=== general requirements ===<br />
* manage membership easily<br />
* assign members to a group / to a activity<br />
<br />
=== Requirements from Hackerspace ===<br />
https://www.hackerspace.lu/wiki/Membership_Management_Tool#Requirements<br />
=== Requirements from LiLux ===<br />
<br />
== By Iteration ==<br />
<br />
=== Iteration 0 ===<br />
<br />
Code cleanup / preparation:<br />
* make it run with error reporting on<br />
error_reporting (E_ERROR | E_WARNING | E_PARSE | E_NOTICE);<br />
* put as many items as possible into functions and/or objects<br />
* set it up as SSL<br />
<br />
=== Iteration 1 ===<br />
<br />
Usability improvements for admin<br />
* 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:<br />
** "delete" (with confirmation)<br />
** "membership card sent"<br />
** "paid this year"<br />
** "CSV list of checked users"<br />
** "Latex mailing include of checked users" (template, see below)<br />
* In the view for individual user<br />
** provide "Delete this user" button (with confirmation)<br />
** provide "Paid membership card for this year" button (with some indication whether already set)<br />
** provide "Membership card sent for this year" button (with some indication whether already set)<br />
* In "Edit payments" provide the option to edit and delete existing payments (for instance, if a typo was made in year)<br />
* Some new views. These views should have same mass actions as "View all entries view" described above<br />
** "all users who have paid this year, and whose membership card was not yet sent".<br />
** "all users who have paid this year or last year"<br />
** "all users who don't have a post address"<br />
** "all users who never paid"<br />
* The implementation of the views should be modular, so that it easy enough to add some more (function that takes a title and<br />
parts of select statement that choses the users to be displayed).<br />
* Remove "Modify entries", "Edit payments" and "Download CSV list": indeed, these functions are now more easily accessible from the views.<br />
* Sort order of views can be changed (by clicking on the relevant column header)<br />
* Add male/female column (useful for proper "Anrede" in mailings)<br />
<br />
Example of Latex mailing template:<br />
\adrentry{Paul}{Muller}{42, rue de la vallée \\ L-4242 Hannerkléngwäinhäffen}{m}<br />
\adrentry{Marie}{Gelatine}{19, rue de la forge \\ L-1234 Knapphouschent}{f}<br />
<br />
=== Iteration 2 ===<br />
<br />
Access by the user himself to his records<br />
* User can request a password to be sent to him to his e-mail address<br />
** This can be sent right at registration<br />
** At a later time, user may request password by pseudo or by e-mail<br />
* User can use this password to view his own record<br />
* User can change his password<br />
* New views (for admin):<br />
** users with un-confirmed email<br />
** users with confirmed email<br />
* New fields:<br />
** Exact date when payment (and extrait number) was received<br />
* Date of payment visible to member himself, extrait number should only be visible for admin<br />
* Support for more than one payment per year<br />
* Management of "in kind" contribution (such as, helping at an event)<br />
<br />
<br />
Note: Extrait number is useful to more easily help confirm at a later date that we didn't do a mistake.<br />
<br />
=== Iteration 3 ===<br />
<br />
LDAP integration<br />
* New users should automatically be created in LDAP<br />
* Admin can "confirm" users, and grant them certain privileges<br />
** local Unix account<br />
** mail<br />
** ...<br />
* Unconfirmed users should not be able to log in, and should not have any other rights on the system.<br />
* New view:<br />
** Unconfirmed users<br />
** Confirmed users<br />
<br />
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)<br />
<br />
=== Iteration 4 ===<br />
<br />
More usability:<br />
<br />
* Admin may define new views in GUI (by supplying a title, and part of an SQL statement that selects the wanted users)<br />
* Persistent user sets (after having ticked a number of user, admin may save this as a set for use on a later date)<br />
* Admin may define new output formats (in addition to CSV and Latex mailing list)<br />
* More than one admin<br />
* Admin with read-only (or otherwise restricted) rights<br />
* 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.<br />
<br />
=== Iteration 5 ===<br />
<br />
Multiple clubs:<br />
<br />
* Admin of a club may only view his own members<br />
* There is a super admin who sees all clubs/defines new clubs.<br />
* For views and output formats, there are now 3 levels of scope:<br />
** all admins of all clubs<br />
** admins of same club<br />
** only that admin himself<br />
<br />
Note: If need arises, we may put this iteration somewhat earlier in the schedule.<br />
<br />
== Existing software/tools ==<br />
=== software ===<br />
* http://archreactor.org/wiki/index.php/AROS<br />
* [http://membership.scouthub.org/ MemberShip]<br />
* [http://code.labitat.dk/index.php/p/member-dev/ member-dev]<br />
* [http://webcomite.com/default_fr.htm webcomite]<br />
<br />
=== tools ===<br />
* [http://www.nubuilder.com nuBuilder]<br />
* [http://limbas.org Limbas]<br />
<br />
=== related sites ===<br />
* https://www.hackerspace.lu/wiki/Membership_Management_Tool<br />
<br />
<br />
== suggestions: ==<br />
=== LDAP ===<br />
* user data, can be standard schema + whatever we may additionally need<br />
* would facilitate SSO functionalities, incl. integration with misc tools such as CMS, Wiki, shell access, ...<br />
* not complicated to set up and get running<br />
* tutorial available for instance from LinuxDays 2003, server tutorial<br />
* LDAP can be frontend to SQL database</div>78.141.149.18