1 - Integrate fsfe-cd with "fsfe-cd"

Current fsfe-cd implement its own SQLAlchemy mapping by mimicing what it sees in the database. There's a newer and more complete SQLAlchemy mapping for the same database which we have here: We would like to integrate these so they use the same mapping. The advantage would be that if we do, then the new has all the support which is needed to not only read but also change database fields, and knows what to do when some fields are changes (send email to inform about changes, etc).

So this milestone would be complete when fsfe-cd uses the from supporterdb instead of its own.

2 - Present settings in settings view

When this work is completed, someone can login to and see their current settings, address, etc, retrieved from the fellowship database. This requires implementing an API call from ams-front to http://fsfe-cd/api/fellows/ to get the information relevant, and fsfe-cd needs to be passed appropriate authentication parameters with it (taken from the User object of the logged in user, specifically the access code and id token).

The parameters which should be published and be able to be viewed in this pane include:

3 - Change settings in settings view

When work on this milestone is completed, it's possible to not only view the information in the settings page, but also change it. The same settings as those in milestone 2 should be changeable. This requires implementing a new view in fsfe-cd to handle changing data. When an API call to change information is received, the updates should be made (can be done directly, since at this point the integration of the new mapping from 1 is done).

4 - Account registration

When this milestone is complete, it's possible to sign up to make a one time or regular donation or create a new volunteer account via the website. The forms are largely there already. but the processes will look a bit different:

When a form is processed, it should call fsfe-cd with the data provided, and fsfe-cd should use the functions from the new to create the relevant objects.

When creating an account, it's vital to check if an account with that email already exists! If it does, the user should be given a notice about this and be asked to login using email. This doesn't apply to one time donors though; if an entry exist for one time donations, we should simply call the executable with the new information and the executable will deal with matching this to the existing account.


The mail sent when person.purpose = 'x' should contain a one-time login link to the website, with the message "to continue your registration, click here". The login link should be created the same way as when someone clicks to login with an email link on The link should direct the user to a page

Teams/Ams-Hackers/WP1 (last edited 2017-11-24 09:04:42 by jonas)