Project Specification and Requirements

This document is used for understanding the requirements and specifications that drive the project. For details regarding the implementation choices, other documents will be created and maintained during the development process.

Document outline:

• Stack
• Security and Authentication
• My Profile (Page)
• About the Department (Page)
• Leader Panel (Page)
• Team Builder
• Active Team
• Future improvements and ideas

Stack

We are building a server-less PWA using Vue JS javascript framework on the frontend, using Vuetify for fast UI development. For data management and security, we will be using Firestore and Auth modules from Firebase. Frontend.

• Vue JS
• Vuetify
• Firestore
• Firebase Auth

Security and Authentication

We will be using the Firebase Auth module for user management. For the MVP, we will support the following two methods of creating an account:

• Email & Password
• Facebook login

In order to enable logging in with facebook, we will have to create a Facebook app.

My Profile (Page)

Route guard: The user must be logged in to have access to this page.

In this page, the user (volunteer) will have access to the following information:

• Volunteer Id:
• Name
• Profile Picture (if logged in with Facebook)
• Default role, if there is one
• Status: registered, not-registered, active;
• Active role (if status is active)
• Volunteering history

The user will have the possibility to register for serving the next Sunday, or cancel registration if he can no longer make it. The user can do this by clicking the action button under the default role. The button will reflect the current status of the user.

The state will be reset to not-registered at the beginning of each week (Monday), and another item will be added to the end of the history of the user for the Sunday that has just passed.

The button to register for volunteering will only be active until a certain day and time in the week (for example, Saturday at noon). After that, the leader is expected to build the team. The leader or admin can still register volunteers for serving if the case is ever presented.

The history will be displayed in the form of a mosaic of squares, each colored by the role the user had in the corresponding Sunday, since the account was first created.

About the Department

Route guard: The user must be logged in to have access to this page.

This page will contain all the rules inside the department: rules of conduct, informations about each role, FAQ and so on.

Leader Panel (Page)

Route guard: The user must be logged in and have leader priviledges to have access to this page.

Leaders can access a list of all members in the department, next to which they will see a snippet of the statistics.

To do: what does the leader need to see next to the volunteer? Is an icon like 'needs attention' enough? When do we display it?

When the leader proceeds to a volunteer page, he will have access to the following meta:

• How long since the volunteer was last active?
• Is s(he) in a default team?
• Maybe show an activity graphic, like how active he was on each role

Team Builder

Route guard: The user must be logged in and have leader privileges to have access to this page.

The leader will have access to a table, initialized with all volunteers that are enrolled on the first column and their gender on the second. The next four columns will contain their scores for each department role, by which the leader can filter the table and deduce the best position that fits a volunteer for the next Sunday. Liderul va avea aici acces la un tabel populat initial pe prima coloana cu toti voluntarii inscrisi pentru slujire.

The last column will contain a dropdown select on each row, from which the leader will select the volunteer position in the team. This dropdown will only have predefined value for the volunteers which have a default role, but can be overwritten even in that case.

When the team is completed, the leader will click SAVE, and the team will be stored as the active team. The next things need to happen when this action is performed:

1. For each volunteer from the active team, the status needs to be set active and the activeVolunteering property value needs to be set to the position defined in the table.
2. For all volunteers, a new position will be added at the end of their corresponding history, for the Sunday for which the team was just saved, of the value:

• if he is on the active team, the active position
• else, 'N/A'

3. Save the first and last column of the table in the database, as the active team.

Active Team

The active team during a Sunday can be viewed publicly. This is necessary as it may need to be shared across multiple departments.

On this page, the active team can be viewed as a table having the Volunteer name on the first column and the active position on the second. Think about formatting each row according to the volunteer role.

Future Improvements