Volunteer Dashboard
Project Summary
MyPickle is a not for profit company, with a mission to make finding help easier online. Everyone at some point in their life will encounter an issue that they will struggle with, and Google is sometimes not the best port of call when in a crisis. The MyPickle website features a charity search engine, powered by a curated and vetted database of charities which have been crowdsourced by volunteers. Through MyPickle, anyone facing a challenging time in their life, can search for their issue and be provided with a list of curated charities that may be able to help them, without the rabbit holes they may have been led down by other search engines such as Google.
I have been volunteering with MyPickle since 2019, and have helped them with various technical problems. In this portfolio piece however, I will only be taking an in depth look in to one of my latest projects for the not for profit.
MyPickle wanted a lightweight website for volunteers to submit listings to their database. It needed to have these basic features:
- Ability for volunteers to submit new charities for review, and manage their submissions
- Ability for Quality Assurance team members to review volunteer charity submissions and provide relevant feedback
- Ability for admins to manage user accounts and export listings
- Ability for the fields on the listing form to be easily changed, without corrupting previous form submissions
Major Challenges
Overall Knowledge of Python Flask
I opted to develop this software in Python Flask, a language I had only used a few times in the past for personal projects, and definitely had never followed best practices. Developing a website to be used by up to a hundred volunteers was frankly out of my comfort zone, but at the time I was the only volunteer with the experience with Python Flask needed to undertake this project.
I had to spend hours of time researching best practices for medium sized Python Flask projects, and even more time ensuring that anything I created was secure. Which brings me on to the next challenge.
Security of the site
The website had to be secure. The website by design would store hundreds/thousands of crowdsourced charity information listings. On its own, this is fine, however it was the aim of MyPickle’s CEO to use this information as a product offering for various companies – to further fund making this information easier for the public to access, so the integrity of the raw information my site would store, needed to be protected.
Secondly, and most importantly, volunteer information needed to be kept secure. I concluded fairly quickly that the site would store very limited volunteer information – name, email and nothing else – and to achieve this, the website would have to integrate with some form of SSO provider (I opted for Google) another level of complexity that I had to learn from scratch.
Permissions
The website had to have a simple permissions system, to ensure that users could not access resources they where not authorised to use. I opted to approach this issue by powering everything by creating my own session management system. Basic authorisation looks like this
The above flow only verifies a user has the most basic of access rights to the system. After this, every endpoint confirms whether the user’s permission group grants them access to use that specific resource.
Form Versioning
Arguably the most difficult part of this project, was figuring out how to handle different form versions. I struggled to find resources online to match my specific use case for this issue.
When volunteers submit new charity listings to the website, they fill out a form which asks for various information such as details about the charity, any helplines the charity offers, why the resource is useful etc. This form needed to be easily changeable, whilst still preserving the usefulness of data from previous versions.
As an example, if I submitted a charity listing and populated a form field ‘Telephone Number’, and then a year down the line deleted this field from the form, the telephone number would still be stored in the database, but it would be almost meaningless as the field which initially described the data would be deleted.
To fix this issue, I created a form versioning system. Essentially, in the root of the web app, there is a directory ‘Forms’, inside this directory are numbered directories e.g ‘1’, ‘2’…’X’ where X is the latest version of a form to be displayed to volunteers when filling out a new listing. Inside each directory are two files, form.json and categories.json. form.json contains a JSON representation of the latest form, with various categories, form fields and options etc. When an admin wants to update the form, they simply copy the latest form directory, increase the number by one, and then make the changes they want to in the copied form.json file.
Now, when a user who submitted a listing on form version 1 for instance, goes to view their submission, the system retrieves the form outline from forms/1/form.json and matches the stored submission values from the database to the corresponding fields in the JSON file. However, when a user wants to create a new charity submission to the database, the latest form version X is used so they are on the most current version of the form.
The End Solution
