Teams/Ams-Hackers/Requirements

Overview of the current situation

In general, data is exchanged between the systems using transactional encrypted e-mails. The mails are generated primarily from the web server and sent to the GNUe host for processing, there there are also some emails going in the other direction. The encrypted e-mails are sent via a private VPN. Data is stored in two primary data stores at the moment, LDAP and GNUe (running on separate machines), according to the following:

Roughly speaking, the current systems consist of the following components:

Here are some of the processes, with a rough indication of how the various components fit together:

New registration for Fellowship/donation

  1. The new Fellow submits his/her email, name and amount to pay on our web pages [PLA]
  2. A (deactivated) ldap entry is created and the user shown a password [PLA->LDAP]

  3. A <CREATE> mail is sent [PLA->GNUE]

  4. A user entry is created in the Fellowship database and welcome mail sent [GNUE]
  5. User is shown payment information (link to Concardis, Paypal or bank information) [PLA]
  6. If user pays with Concardis or Paypal, those systems sends a notification to us which is received on a webserver [CGI]
  7. Payment information is processed and send by meil [CGI->GNUE]

  8. User is activate with an <ACTIVATE> mail [GNUE->MAIL]

  9. When the user logins (with password from 2.), he/she is asked to set a username (so far we only have email), information of which is sent as a <SET_PROPS> mail together with address information and other properties [PLA->GNUE]

  10. When the username is set in GNUe, this sends a <SET_LOGIN> message to update the ldap accordingly [GNUE->MAIL]

  11. If the user requests to see his/her data, a <REQUEST_PROPS> mail is sent, which causes GNUe to *mail* the information to the user [PLA->GNUE]

New registration for volunteer:

  1. The new volunteer submits his/her email, name on our web pages [PLA]
  2. A (deactivated) ldap entry is created and the user shown a password [PLA->LDAP]

  3. A <CREATE> mail is sent [PLA->GNUE]

  4. A user entry is created in the Fellowship database and welcome mail sent [GNUE]
  5. User is asked to get in touch with a group coordinator [PLA]
  6. A group coordinator verifies that the volunteer should have an account and informs fellowship@fsfeurope.org

  7. Reinhard and/or Jonas manually activates the account in GNUe [GNUE]
  8. User is activate with an <ACTIVATE> mail [GNUE->MAIL]

  9. When the user logins (with password from 2.), he/she is asked to set a username (so far we only have email), information of which is sent as a <SET_PROPS> mail together with address information and other properties [PLA->GNUE]

  10. When the username is set in GNUe, this sends a <SET_LOGIN> message to update the ldap accordingly [GNUE->MAIL]

  11. If the user requests to see his/her data, a <REQUEST_PROPS> mail is sent, which causes GNUe to *mail* the information to the user [PLA->GNUE]

User wants to reset the password:

  1. User submits a request to change password (using email or username) [PLA]
  2. A cookie is set in the user's browser with information [PLA]
  3. An email is sent to the user with a confirmation link [PLA]
  4. The user clicks/copies the link, the cookie is checked to still be valid, and this causes a new password to be generated [PLA]

Change requests

Work packages

The question here is how to structure this work in a reasonable way so we can work on it piece by piece. This is complicated by the fact that some of the changes we want to make necessitate changes both to GNUE and PLA, and probably LDAP and MAIL as well. So it's not so easy to just break pieces out from the whole and update them separately. However, at the cost of needing to re-do changes later, it's of course possible to resolve some of our immediate needs and many of the change requests we have. We can then approach the other change requests in a structured way afterwards. This is an example of what the work packages could be: