search

RachWalm / VolunteerVillage

Project 4 for Code Institute
0 stars 1 forks source link

readme

Volunteer Village

Introduction

Welcome to Volunteer Village.

It can be accessed through Volunteer Village.

title

The volunteer village site was designed to be used by people in two roles for a charity that connects volunteers with those in need.

The first role is as a volunteer looking to provide voluntary assistance. The second is as a coordinator at Volunteer Village who's attempting to match people and charitable organisations who are in need of assistance with appropriate assistance. The volunteer signs up and provides contact information and details of the kind of assistance they are able to provide and when they are likely to be available on a weekly basis in a profile form which is saved.

The second role of coordinator can search the volunteers' profiles to be given a list of people who can provide that type of assistance at that time to match them with requests external to the system.

UX design

The aim is to have a landing page that is enthusiastic about volunteering. This should hook the volunteer without making it seem like hard work. From there a new user (coordinator or volunteer) can sign up, select their role and fill out a profile form.

When not logged in n the index page the user has two buttons to sign up or sign in as calls to action in the top right.

On every page there is the logo for volunteer village which is based around a helping hand coming out of the dark surrounded by holding hands circle motif and has the words volunteer village in the centre. This is mirrored in the favicon on the tab. Also on every page when the user is logged in there is a box (surrounded by shadow - to emphasize it isn't part of the nav) which lets users know what user name they are logged in as incase they have different logins for different roles. The nav is permanently there to take the user to the homepage and relevant pages to the area of the site they are on and who they are logged in as. As far as possible things were kept consistent to allow the user a sense of continuity.

As a volunteer they can then see their profile, edit it and delete their personal details from the account, having created it at the beginning of the process.

As a coordinator the user can activate accounts of other coordinators, modify and delete other coordinators / their own account. It is anticipated that coordinator would be working for a small voluntary organisation so there is unlikely to be any HR/IT department to modify other coordinators. Joining or leaving or name changes would need to be editable by coordinators for each other.

Next a coordinator will need to be able to search the list of volunteers by activity and when they are likely to be available, then read their contact details to contact them. So there is a search for volunteers. This doesn't allow any modification/creation/deletion function as their personal data is to stay under control of the individual volunteers.

Coordinators will also activate the volunteer profiles. This is a manual check which has two purposes: to check it isn't a spam profile and to consider if there are already known volunteering opportunities for them.

The layout of the site was improved and made responsive using bootstrap and the background colour was set using CSS. The principal use of bootstrap was to move the main part of the page from being stuck to the left / start. Then each item is put in an appropriate place and break points are used to add responsiveness.

Bootstrap was mainly used for moving items to appropriate places using the grid, but also for putting into place some colour coding to make the appearance throughout the site consistent. Functions such as the .nav and .table allowed these to be set up very simply.

Using bootstrap meant that I could use the built in colours for bootstrap which are functional and provide a familiar context to users.

The required functionality and beginning of the nice to have functionality is in Epics/User stories/Tasks as shown below.

Wireframes

The initial wireframes that were built were for an index page to draw in the volunteer, for a volunteer profile page that can be created and updated by people wishing to volunteer, a page explaining how to use the system (not currently implemented) and a coordinators page. Some of these had both large monitor and small device setups displayed. Wireframes were not created for the nice to have pages at this stage such as the charities section and feedback and likes sections.

As some of the nice to have ideas were incorporated some of the initial layout/wireframes designed became redundant, it was necessary to deviate from some of the initial wireframes (the Index page followed the wireframe idea). The create volunteer profile page only had one major change to the layout and that was rather than toggles for the activities it was decided that a select list would be more pleasing on the page (as there are already so many radio buttons for the days and times). The coordinator page was completely redesigned as additional functionality other than just the search has been coded (additional nice to haves such as charity section). Therefore, the coordinator page now shows how many people need activating and links to perform tasks. The volunteer search page just provides textual results as it was decided that the picture/avatar of the volunteer didn't add any value due to it only being seen by the individual volunteer and coordinators who were unlikely to ever meet the volunteers.

The nice to haves were not wireframed - what they would look like is not relevant in the initial design for minimum working site meeting volunteers matching activities requirement.

Relationship diagram

The different apps and relationships were discussed and as the idea formed a rough initial relationship diagram was developed.

Initial idea diagram

relationship diagram

As can be seen from the relationship diagram sketch the additional Charity section and Star Rating section were considered to avoid future problems should they be added at a later stage. The main bulk of the project centered around getting volunteers to sign up with details and coordinators to search them. Therefore we started with a user, this was intended to be through allauth and would sign up everyone that used the site (except admin/superusers). The user then had a one to one relationship with a profile (whether a coordinator profile or a volunteer profile).

Final implemented diagram

final relationship diagram

Epics / User Stories / Tasks

Each issue that was raised for the git projects boards contained acceptance criteria and steps to be taken to complete the issue. In the title they were described as Epics, user stories, or tasks depending on the depth of the requirement.

These were put into milestones and labelled as iterations each one to be closed on a Monday with planning of what user stories and tasks would be prioritised that week and the backlog being considered of unfinished work from previous iterations. Prioritisation was acheived using labels of priority that week (labels were also used to define bugs). This can be seen on projects.

Epics

The Epics were assembled about a week into the project when the scope became apparent as to how much could be achieved. All apart from the last #71 of the epics below were implemented. Until that point userstories were put in place for any work immediately apparent.

Issue Title
#66(Epic : new to the site ) As a potential volunteer , I can see the site aims and navigate to how it works page so that I can decide whether to use it.
#61(epic:Volunteer joins site) As a volunteer, I can join the site and put in my profile so that I can be ready to volunteer.
#65(Epic: Volunteers can only see/update/delete their own information and only when logged in ) As a volunteer, I can join the site and put in my profile so that I can be ready to volunteer.
#63(Epic: Volunteer reads their profile) As a Volunteer, I can look at the preferences I have chosen so that I can be confident they are correct.
#62(Epic: Volunteer update their profile) As a volunteer, I can update my profile so that I can make any changes as time goes by.
#64(Epic : user can delete profile ) As a Volunteer, I can delete my profile so that I can stop using the site and stop them having access to my details.
#67(Epic : Coordinators can be registered and log in and out) As a Coordinator, I can register and log in and out so that I can do my job.
#69(Epic: coordinators can be approved) As a approver, I can get coordinators onto the system so that I can get them coordinating.
#68(Epic : coordinator can search the profiles to find someone to do the volunteering) As a coordinator, I can search for a suitable volunteer so that I can match the activity to a volunteer.
#104(Epic: Coordinators can activate the volunteers profile) As a Coordinator, I can look at new profiles and consider them for old projects and then activate them so that I can check for spam and see what is newly available.
#85(Epic: if user isn't logged in but URL for a logged in page typed send to error page) As a site user, I can type the url but not be logged in so that I can see a useful information error page rather than url not found etc..
#70(Epic: charities section of website set up) As a coordinator, I can create update and delete and read info on charities so that I can use this as a source of information.
#71(Epic: ratings and notes area of website created) As a coordinator, I can make notes and rating the volunteers so that I can keep details and keep track of how many hours of volunteering they have done.

User stories and tasks

There were many user stories and tasks that were set up to ensure that individual functions and requirements didn't get forgotten which can be accessed by issues.

Features

Existing Features

Every page that should be restricted use to coordinators ensured that that only authenticated people can use it in the HTML with an if user.is_authenticated and a check by the function in views role_authenticate, which checks if they are of the correct role and if they have been activated by a coordinator. This means that an unactivated coordinator or any unauthorised persons would not have access.

Index page

The index page has the same basic heading and footer that is on every page.

The heading contains a logo, title and the home page and allauth navigation links. It also contains a message as to who they are logged in as or if they are not logged in a call to action with sign up and sign in buttons. This area also has flash messages in the center when they are relevant.

The rest of the page is text and images chosen to draw a new user into the idea of volunteering and provide information on what volunteering roles are likely to be available.

index

The footer has information about the developer and states that the website is a project is for Code Institute.

Allauth settings

The allauth require that certain settings are put in the project settings.py:

ACCOUNT_EMAIL_VERIFICATION = 'none'

LOGIN_REDIRECT_URL = 'login_success'
LOGOUT_REDIRECT_URL = '/'
ACCOUNT_SIGNUP_REDIRECT_URL = '/role/role'

This proved to be very useful.

  1. The e-mail is optional, and although displayed in the sign up page, can be left blank. This also means that e-mail account verification and forgotten password cannot be used. If they put an e-mail in here it is displayed in their profile, but the display box is left blank if they haven't included it. This means that coordinators will see the e-mail in the display of volunteer details, but as this isn't currently editable and most opportunities will require discussion it is unlikely to be used. Therefore, future development may use e-mail but it is currently just there for information.
  2. Sign up could be directed to the role page so that the first decision to be made after getting an account is which role they want - Volunteer or Coordinator - See above code for redirects.
  3. Log out it was logical just to go to the landing page as it is generally set up.
  4. The log in redirect was probably the most useful as it allowed me to set up a view that used 'if' conditions to determine where to direct the user. This meant that different roles went to the two separate apps, and within that app they were directed to whatever stage of the process that they had completed (depending on filling out details or activation). It took the logged in users information and directed them in role/views.py and this function:
def login_success(request):
    """
    Redirects users based on the role and what stage of the sign up
    process they have completed to area they need to use the site.
    """
    pk_logged_in = request.user.pk
    role_exists = Role.objects.filter(user_name_id=pk_logged_in).exists()
    if role_exists:  # role is chosen
        # sees whether they signed up as volunteer 1 or coordinator 2
        title = Role.objects.filter(user_name_id=pk_logged_in).values()
        # checks if they have a profile stored
        vp = VolunteerProfile.objects.filter(user_name_id=pk_logged_in)
        VP_exists = vp.exists()
        # checks if they have a profile stored
        cp = CoordinatorProfile.objects.filter(user_name_id=pk_logged_in)
        CP_exists = cp.exists()
        # gets profile so can check if activated
        co = CoordinatorProfile.objects.filter(user_name_id=pk_logged_in)
        co_profile = co.values()
        # volunteer with profile
        if title[0]['role'] == 1 and VP_exists:
            # see volunteer profile
            return redirect('read')
        # volunteer without profile
        elif title[0]['role'] == 1 and VP_exists is False:
            # form to fill out volunteer profile
            return redirect('add')
        # coordinator without a profile
        elif title[0]['role'] == 2 and CP_exists is False:
            return redirect('addco')  # form to fill out coordinator profile
        elif title[0]['role'] == 2 and CP_exists:  # coordinator with a profile
            # coordinator with a profile and activated
            if co_profile[0]['activated']:
                return redirect('dashboard')
            # unactivated coordinator so no access
            elif co_profile[0]['activated'] is False:
                return redirect('pending')
            else:
                return redirect('index')  # just in case
        else:
            return redirect('index')  # just in case
    else:
        return redirect('role')  # hasn't chosen role yet

Sign up page

This page is built by allauth, but also has the header and footer as previously described. This was achieved by copying the templates from allauth and extending the custom base.html.

signup

Email verification is set to none in the settings, this field is optional.

Sign in page

This page is built by allauth, but also has the header and footer as previously described. This was achieved by copying the templates from allauth and extending the custom base.html. On this page the 'forgotten password' link was also removed from the standard template used by allauth - as that functionality has not been set up. It was necessary to go to an old version of allauth to have this visible in the HTML for it to be removed.

signin

Sign out page

This page is built by allauth, but also has the header and footer as previously described. This was achieved by copying the templates from allauth and extending the custom base.html.

signout

Role choice page

This page is part of the sign up process. As users can either be signing up as a volunteer or as a part of the organisation as a coordinator. The dropdown select has volunteer as the default, and only one visible when they arrive at the page. Volunteer is the main option chosen and one we want the public to focus on. Other option selected by coordinators as needed.

role

This page currently only has the option of volunteer or coordinator. This could be simply updated as each role is associated with a number to allow for additional roles (such as charity login or different types of coordinator should the organisation grow to require multiple more focused coordinators or should the orgnaisation want the activities restricted to certain personnel of differing responsibilities).

Currently, 1 is volunteer and 2 is coordinator. Where it is required that access is blocked 0 is the integer to be returned from the function role_authenticate which is used to restrict pages bringing up their content unless it is a coordinator who is activated - so has a role of 2 and profile value for activated is true.

Coordinator add profile page

As the information on this page will be visible to all the coordinators it doesn't contain excessive personal information, it just requests first and last name. This should be sufficient for information in connection to the coordinators - so people know who to contact when getting the coordinator details. This information is placed into the CoordinatorProfile model.

These fields are saved in the CoordinatorProfile and attached to the User via a one to one field.

Pending activation page

As the coordinators will have access to almost all functions and large quantities of data, there is then a step where another coordinator needs to activate the incoming coordinator. This will prevent accidental or malicious access as a coordinator. This Pending page is the page that the coordinator is directed to between them signing up and being activated - even if they log out and back in unless they are activated they will go to the Pending page. If they inform another coordinator that they need activating other coordinators can perform this (see below).

pending

Volunteer add profile page

If the role of volunteer has been picked then this takes them to the volunteer add profile page. There is little action that a volunteer would want to take without a profile so this is the first place directed to. This page requests information such as name, phone number to contact to volunteer with volunteering opportunities. It also establishes which of the activities from the list they would like to do and when they are regularly available. There is a free text box to add any special skills etc that they want to have highlighted.

voladd

The list of activities that they can pick from is taken from the database which holds a list of activities and they can select several by holding down control (holding control is stated in the help text on the page).

The sessions that they are able to attend are boolean fields so that they can be easily switched on and off. I had imagined that they would be laid out in a grid that would account for days being on a row with the times throughout the day being in columns, but with the form display being the most efficient option, this idea was discarded.

JS validation

This is saved in the VolunteerProfile and is connected to the User via a one to one field.

Volunteer read their profile page

The volunteer is sent to their profile read page when they have added their profile, or log in with a profile in place. Here they can see the information that is held on them. There is also the option to edit the profile - which sends them to a page to perform that (described below), or delete their profile (which is described below).

This isn't editable on this page to avoid accidental clicking and making inadvertent alterations.

volread

Most of the data is taken from the VolunteerProfile model (except the e-mail which is taken from the User allauth model).

There are a couple of functions involved in producing this page as there are several items that have multiple either inputs or outputs. Therefore iterating through lists both in the html to display them on the page and searching through a list of model fields to check if the one required is 'true' while not displaying the field activated as 'true'.

If there hasn't been a profile set up for the person or the user not logged in then this page will go to a 404 error, and won't display any erroneous information. This protects information being viewed by anyone but the volunteer through this page.

Volunteer edit their profile page

If a volunteer clicks to edit their profile then they are directed to a page that is similar to the form where they added their original profile and is populated with the currently held information. To edit they must make the relevant changes to the form and then press submit. Unless submit is pressed no changes will be performed.

voledit

This currently does not have the ability to change the e-mail as that is taken from allauth and this form is based on the VolunteerProfile model, so that is not on the form.

Volunteer can delete the profile information

If a volunteer no longer wants their information to be held then they can choose to delete the information. In the read volunteer profile page there is a delete button, this leads exclusively to their (logged on as) details on the database so they can't delete others details. The delete button doesn't instantly delete it goes to a Javascript coded modal which informs them that the delete cannot be undone and then has the delete button or a cancel button. This prevents unintentional deletion by an accidental button click.

It does allow the user to remove their information and also deletes the details for username and password etc.. Once they have confirmed the delete it takes them back to home page where they could sign up again.

Delete modals

The code for the delete modals were taken from the extra tutorial which carried on from the code institute blog tutorial that was posted on slack. 

<div class="modal fade" id="deleteModal" tabindex="-1" aria-labelledby="deleteModalLabel" aria-hidden="true">
    <div class="modal-dialog">
        <div class="modal-content">
            <div class="modal-header">
                <h5 class="modal-title" id="deleteModalLabel">Delete comment?</h5>
                <button type="button" class="btn-close" data-bs-dismiss="modal" aria-label="Close"></button>
            </div>
            <div class="modal-body">
                Are you sure you want to delete your comment? This action cannot be undone.
            </div>
            <div class="modal-footer">
                <button type="button" class="btn btn-secondary" data-bs-dismiss="modal">Close</button>
                <a id="deleteConfirm" href="#" class="btn btn-danger">Delete</a>
            </div>
        </div>
    </div>
</div>

This code was taken out of the tutorial that was posted on slack as an extension of the blog walkthrough and adjusted to the three delete modals (volunteer profile, coordinator profile and charity). As the delete button pointed to the modal not directly to a delete, Javascript was then used with an event listener on the modal delete button which then pointed to the url.

Coordinator dashboard page

This is where active coordinators are directed when they log in (and are activated) and is the centre for all the links that they will need to perform routine requirements.

dashboard

This page also informs them about the state of the volunteer and coordinator activations for processing. The number of activations of both the volunteers and the coordinators that need actioning is displayed on the screen. The names of the coordinators are also on the screen so that as they will be able to search coordinators (as the first name is displayed on dashboard copied to search) in order to activate them. This will ensure the correct spelling when searching. There are likely to only be a few at a time so this list doesn't take much space. If there are a large number of spam profiles they can determine who is legitimate without waiting for a superuser to deal with the spam profiles.

The volunteer activation page provides a list of all volunteers that need activating so there is no list of the volunteers on this page and it is expected that this would hopefully be a much larger list. If there are no volunteers that need activating then the count of volunteers will read 0 and the button to go to the volunteer activation page will not be displayed. Not displaying that button avoids going to a search page that is empty and could cause confusion to users.

From this page they can perform the following activities by following links to :

Forms on pages

All forms undergo csrf tokens to avoid any fraudulent behaviour.

Forms that can be taken directly from the models are, as they will save to the models and are created using forms.py and put in the HTML as that form.

Searches use text inputs are created individually in the HTML and are not saved in the database.

Search pages

All search pages are created with individual inputs in the HTML and the lists for the options are created from data that is saved in the database.

searchco

Coordinator activate/edit coordinator profiles page

If a coordinator signs up to the site there needs to be a restriction on their access as they will have functionality and data access that shouldn't be freely available, so another coordinator has to activate them by ticking the box and submitting. This page can also be used if the coordinator wishes to change their name - marriage, legally changed name etc. As it isn't anticipated that any organisation like this would necessarily have an HR role, name changes will be by the coordinators. Should a coordinator leave temporarily (such as parental leave), then the account will need to be deactivated to restrict access to the information.

activateco

There is a many to many relationship between charities and coordinators which as it is attached to the charities model this page (unlike the see coordinator profile page) does not have which charities the coordinator is associated with.

Although the functionality to delete coordinators is currently in place (a necessary security risk if there is no IT or HR dept), this may need to be deactivated if the function to enable commenting on the volunteers activities were to be implemented. As if that were implemented and coordinators were making the comments and being recorded as making the comments then deleting the coordinator could be problematic. This delete coordinator functionality is included currently as it has no impact on other functionality and might be required. Were it necessary to remove the delete coordinator functionality to allow other things that require legacy data to function properly then the activate function could be used to deactivate a coordinator restricting their access but not their history.

In the event there are no coordinators activated this could be performed for one coordinator by the superuser in the admin section.

Coordinator search for volunteers page

When a request has been made to the organisation for a type of activity to be performed during a certain part of the week a coordinator can go to the search page and select the activity and the day and whether it is for morning/afternoon/evening and if any of the volunteers fit this description then their name is displayed as a list. The information about the volunteers is then displayed in a non-editable table on screen. Coordinators could then contact the volunteers and organise the activity that is required.

searchvol

Whether a volunteer is activated or not they will appear in this search. Should the function later be required to display only activated volunteers then this requirement could be easily added as a filter - using the reverse of the filter that lists unactivated volunteers on the dashboard page.

Coordinator activate volunteers page

activatevols

Coordinators are required the activate the volunteers for two reasons: to look at incoming volunteers and see if there are any unfulfilled volunteering opportunities that would suit them (providing volunteering activity promptly to volunteers as they join the site which will increase thier enthusiasm for the process), and to ensure that the database doesn't get filled up with spam profiles. Reading the information provided in the text box by volunteers may also be more useful that just having their choice of activity if they have a special skill that can be matched.

activatevol

Coordinator add charity page

Should a new charity wish to be involved then the coordinator can click on the link in the dashboard and add the charity name and a few details in the text box about the charity's needs and information. The charity can also be assigned a coordinator (or a couple as back ups, or many for a big charity). Then the information is there to enable the most appropriate person to deal with a charity's request (or if that person is away, provide enough information in the text box for someone else to assist).

addcharity

Coordinator choose charity page

Once a charity is in the database then coordinators will want access to the information to read/edit/delete. This page allows coordinators to search by the name (partial or full) of the charity and returns a list of the charities that fit the searched text. For each charity there is a look at charity information (which is non-editable to avoid accidental update), an edit and delete button if they need to change the information or if the charity decides to no longer continue the connection.

searchcharity

.icontain should deal with partial or capital vs small letter searches.

Coordinator view charity page

When the Look at charity information button is pressed a read only version of the information is presented.

readcharity

Coordinator edit charity page

On the choose charity page there is the option to edit the charity. This takes the user to a form that is the same format as the add charity form, except it is populated with the currently held information, which can be altered. No changes will take effect until the submit button is pressed.

editcharity

Coordinator delete charity

In the choose charity page there is a delete button, this leads only to the details of the selected charity so they can't delete others details. The delete button doesn't instantly delete it goes to a Javascript coded modal which informs them that the delete cannot be undone and then has the delete button or a cancel button. This prevents unintentional deletion by an accidental button click.

deletemodal

Deleting a charity does not delete any of the coordinators that are stated in the many to many relationship as this is not a ON_CASCADE relationship and the data of who is associated is stored against the charity. Therefore, on look up from the coordinators end for the see profile of coordinators it just won't be there any more.

Defensive programming

The pages where there is sensitive information displayed/updated to/by the coordinator have built into the HTML that the user must be is_authenticated and have a role of 2 which is the integer assigned to coordinators. The pages that display sensitive information to the volunteers use the logged in users information to provide them with just their own information so they can't look at or interact with any other information. This secures the visualisation of the pages. In both these instances the unauthorised user doesn't get to the page and is directed to the 404 error so they can't manipulate the pages in anyway.

All delete functionality is subject to a modal so that they can choose to halt the delete if it has been clicked in error by cancelling or clicking out of the modal.

The delete function for the volunteers deleting their own information is once again defended by using the logged in person as the information that is deleted.

The delete functions for charities and coordinators have the role_authenticate function in the views.py for the delete action to ensure that they are logged in as a coordinator to be able to delete. If they are not a coordinator then they are redirected to the index page without the delete going ahead. As the setting up the role can be accessed only through sign up or via typing the url I have not put in defensive programming here as if attempting to set a role without being logged in it will have an error. If you attempt to add a volunteer profile without being logged in when you press submit it leads to an error.

Navigation bars

The top right navigation bar is for login/signup/logout functionality related to allauth and not specific to the type of user logged in. Or to go to the home page.

Logged in/out at top of page

In the top right of the screen next to the nav bar there is an information message that either provides buttons (call to action) for sign up or sign in or when logged in which user name you are logged in as (people may have a coordinator and volunteer account).

Flash messages

Most activities that involve change contain a flash message. If the user performs an allauth related activity (login/logout etc.) or if the user updates the database in some way a flash message should appear on the screen for 2.5 seconds. Other activities such as searches are apparent by the messages on the screen or results being displayed.

Search text function

This was adapted for the various searches throughout the site that are text inputs from a tutorial on youtube youtube.

        <form method=POST action="{% url 'search_charity' %}">
            {% csrf_token %}
            <input type="search" placeholder="charity name" aria-label="Charity name search" name="search">
            <button class="btn btn-outline-info" type="submit">Search Charity</button>
        </form>
search = request.POST['search']

Superuser/admin activities

Most activities can be performed by the users in one role or another. The below actions need to be restricted so are exclusive to admin area:

Potential Future Feature Developments

There were some functions that could potentially make the site more useful but were outside the prime objective of the site to allow volunteers to sign up and then be matched with requests. These other possible functions were still initially thought through to avoid coding in such a way as to require an extensive recode to introduce them later.

  1. It may also be a useful function if feed back or notes on the volunteers could be made by the coordinators. Possibilities are allowing them to have a star system to show how many activities they have undertaken - reaching certain levels could congratulate the volunteers or entitle them to a different badge or title. Where praise has been given by the people they assist that this could be fed back to the volunteers through their page.

  2. A similar function may be useful where notes on a volunteer from one coordinator to other coordinators could be left that could not be seen by the volunteer. Such as when they have contacted someone about something but it wasn't a match to avoid a different coordinator attempting the same match.

  3. An area to save activity requests from public and charities that haven't been fulfilled would give an open activities area which could be searched.

  4. An area containing success stories and historic information could be quite motivational for the volunteers.

  5. It might be possible to improve the model for the days and times as it would be much better if I had managed to use the initial idea of Monday = 1 Tuesday = 2 etc and am = 1 pm =2 so then Monday-AM would be 11, this would have given a simpler and lesser number of fields. However, with problems (described in bugs) doing the initial volunteer create profile and time constraints it was decided to go simple for booleans. This would also have made searching for the volunteers that fitted the criteria required simpler.

  6. A set of instructions on how to follow the process and what the process involves page would give users confidence that it was working.

  7. Further improvements could be achieved once information gathered from the text box entries of the coordinators' and volunteers' entries - could be assessed to look for recurring themes that could be made into fields rather than these being typed repeatedly.

  8. Real time or calendar inputs for emergency or one off events might be helpful.

  9. It might add clarity if coordinators can change volunteers' availability when weekly commitments to volunteering activities occur. Record volunteering already being done by that individual.

  10. Some follow up tools for coordinators to check back that events worked well or if there could be improvements to the service might be helpful.

  11. Volunteers might wish to search the charities (with the permission of the charity) to know who they might be able to volunteer for.

  12. Email is an option on sign up but should be possible to update and include or change it later.

  13. There could be a section to request assistance. This would mean that where charities or individuals needed to contact the organisation out of hours they could leave a message.

  14. Relate amount of time available to committed already time. It would be useful to be able to know if someone already performs activities at a certain time so although their sessions could reflect that they are open at that time to do volunteer work, that they already have a commitment through the system would allow coordinator not to attempt to double book and volunteers to see how productive they are being.

  15. It may be required for some sort of audit to be able to search everyone involved. These searches for all volunteers or coordinators can use the code that is already in place. This could be achieved by the search functions already in place not filtering anyone out.

Bugs

Bug 1 - Saving form issues

This issue involved a lot of support from the code institute tutor team who put in a lot of work.

Initially the volunteer app was split into three models, VolunteerProfile, Skills and Timeperiod. These all required data to be put into the models from the volunteers via forms.

  1. Firstly, the is_valid function which is required for the save to work would return False for the forms. This meant that it wouldn't save. There were three forms on one page. Therefore, each form was commented out one by one and gotten to work. However, when all three forms were there together then it wouldn't save.

The initial problem was that the below statement was missing:

profile = form.save(commit=False)
  1. Then there were some problems with the need to get the VolunteerProfile to save that worked with allauth so that the logged in user was connected to the data being added.

Some tutors felt that the problem might be solved by saving an empty set of data first so this was introduced to the function.

  1. Then it looked like the indentation had got out of order with so many edits.

  2. Got some of it saving but the select for skills wasn't populated so nothing could be saved from that. Tried putting choices= in the model and many other things adjusted through out the model for Skills and SkillChoices.

This unfortunately made the database have incongruous number of columns in the tables and caused significant problems. This was intially fixed by going into the migrations and adding data, but that was not a permanent fix.

In the end all migrations had to be deleted from all apps and the sqllite database deleted. Then restarting with makemigrations and migrate and creating a super user.

Unfortunately with continued adjustment of the models to attempt to get it to work with taking the choices = in and out several times the database needed deleting (along with migrations) several times.

  1. With the choices = the options were available but you could only make one choice and it was not working properly.

  2. Unsure of how many to many relationships worked I tried to put a many to many at each end of the relationship and got a circular issue.

  3. As I had a working form on another app by this point I decided type that code out for this form and remove the other parts.

Solution

By this point the code was extremely messy.

I decided to retype the form out from scratch with all the models merged into one as I could see no difference in the code that worked and didn't. Retyping the code seemed to solve the problem and so there must have been an error in the code that I couldn't see and was just propagating by typing into it.

Bug 2- Admin site didn't look right on Heroku

The admin site on Heroku was just plain text it had no styling. It would appear that for some reason the css for the admin had disappeared. When this was reinstated on the Heroku version the styling reappeared.

Bug 3- Admin site no longer had VolunteerProfile

As I had been dealing with another error I had commented out the VolunteerProfile in volunteer/admin.py. As soon as this was reinstated it reappeared.

Bug 4 - Admin site had 403 error

This required that 

CSRF_TRUSTED_ORIGINS = ['https://volunteervillage-8a4d89acc796.herokuapp.com', 'https://127.0.0.1']

was added to the settings.py. This was instantly solved by the tutors at code institute and they explained the necessity to include the https.

Bug 5 - Deployed version on Heroku had application error

Initially the requirements.txt was suspected as being at fault as using 

pip3 freeze --local > requirements.txt

had meant that everything that I had experimented with along the way was in this file.

The problem persisted only on the deployed version (codeanywhere and VSCode were fine). There was a 'phonenumberfield' that I had looked into and removed from requirements.txt but not INSTALLED_APPS in settings.py

Solution

This worked when Phonenumberfeild had been removed from INSTALLED_APPS.

Bug 6 - Display of Coordinator profile page not working

This was the feature that was attempting to check if the coordinator was associated with any of the charities. In the case that the user didn't have any charities assigned then it was creating an attribute error. This was worked round with a try: and except Attribute error:statement.

Unsolved bugs

At the very end of the project I realised that the boostrap parameters should go in the div tags (they had often been placed in other tags throughout). This is a widespread bug throughout the project and would take significant time to rectify. As this was only discovered as the final testing and documenting phase started there was insufficient time to go through the code to ensure better practise.

Technologies

Languages used

Databases

Tools

Web resources

Deployment

Heroku deployment

The deployed version can be accessed on Heroku here

Before deployment you will need to collect all the requirments into requirements.txt

pip3 freeze --local > requirements.txt

and create a Procfile (with a capital P) containing:

web: gunicorn volunteervillage.wsgi:application

Ensure that the version that you want to deploy has been added, committed and pushed to GitHub (as Heroku will take it from the repository).

  1. Heroku was used to deploy.
  2. Once logged onto the website, using the drop down menu in the top right we went to the dashboard. dashboard
  3. From here we are able to create a new app either by clicking on the icon (which is what we did)

icon

or the drop down menu

dropdown

  1. Next the app was named volunteervillage and the Europe region chosen in these fields

name

and the purple 'create app' button was pressed.

  1. In the menu navigation bar the 'settings' was selected

settings

  1. The section with Config Vars was then opened up by clicking the Reveal Config Vars button

reveal

  1. The URL's were set, disable_collectstatic was set to 1, port was set to 8000 and the secret key was provided the value. Cloudinary_URL and the Disable_collectstatic were later removed. The database_url was copied from the elephantSQL.

configvars

  1. Now we used the menu navigation bar again, this time to select deploy

nav

  1. The deployment method was selected by clicking on the GitHub icon and it stated that it was connected to github

method

  1. The repository was chosen by searching my github

find connect connected

  1. Automatic deployment was chosen so that it would update every time the changes were pushed to git

auto

  1. It was deployed

deployed

In the final version it needs to have debug (in settings.py) set to False (was True during development) and as mentioned above the DISABLE_COLLECTSTATIC removed from the config vars.

Local Deployment

You will need to pip install the following apps:

Django and gunicorn

pip3 install django gunicorn

dj database url and psycopg2

pip3 install dj_database_url psycopg2

bootstrap

pip3 install django-bootstrap5

whitenoise

pip3 install whitenoise

allauth

pip3 install django-allauth

Or if you wish to install them all at once you can use the requirements.txt file (I couldn't as the requirements.txt is made from what is installed). In the IDE terminal:

 pip3 install -r requirements.txt

Cloning

  1. In the git hub repository, code button clicked
  2. clicked local
  3. choose HTTPS
  4. link copied
  5. went to terminal of the IDE and input the following :git clone https://github.com/RachWalm/VolunteerVillage.git

The project was cloned.

It will be necessary to install the list in local deployment and also set up an env.py and reference it in the settings.

The env.py needs to contain:

import os

os.environ["DATABASE_URL"]="link gained from elephantSQL for the database see below"
os.environ["SECRET_KEY"]="Enter your secret key here"

A .gitignore file must be used and the env.py should be added to it so that the information in there that should be kept private such as the secret key is not put on GitHub.

To run the local deployment in the IDE terminal window :

python3 manage.py runserver

ElephantSQL

  1. Sign up to ElephantSQL and login
  2. From the dashboard click create new instance:

create

  1. Choose and name and plan (tags not needed) and click green select region

nameplan

  1. Select region and click green review button

region

  1. Back on the dashboard click on the name of the instance that you created and then you can copy the url (icon of multiple sheets of paper) to be used on heroku and in your env.py as the database_url.

url

  1. It will require a version that is higher than 12.0 as lower versions will not work. On the right hand side menu click on stats:

stats v12

Once you have a database you will need to migrate the models to the database.

This can be done in the IDE terminal window using:

python3 manage.py makemigrations then python3 manage.py migrate

if you are planning on using the admin area a super user will be required which can be created by:

python3 manage.py createsuperuser

Testing

See Testing

Credits

Images

Mowing lawn Image by senivpetro on Freepik

Women receiving shopping Image by Freepik

Drinking tea No attribution required https://pxhere.com/en/photo/180168

Driving Image by Freepik

Man fixing sink Image by rawpixel.com on Freepik

Desk https://pxhere.com/en/photo/1294988?utm_content=shareClip&utm_medium=referral&utm_source=pxhere

Fundraising Image by Wepik on Freepik

Helping at a stall Image by Freepik

Litter picking

Image by Manfred Antranias Zimmer from Pixabay

Laughing litter pickers

Image by teksomolika on Freepik

Tutor Image by mindandi on Freepik

Adult tutoring Image by Freepik

Women reading Image by Nigel Cohen from Pixabay

Event unloading car

Image by Freepik

Acknowledgements

My Mentor - Juliia Konn has been extremely enthusiastic and provided encouragement and a great deal of support.

My family - Pat Walmsley and Sarah Walmsley have tested the site on their own devices and given very useful feedback.

My Partner - Ian Harris who has been extremely supportive while I have been working on this project.

Code institute - For all the information and course content that has contributed to the creation of this project.

Code institute tutors - Who worked very hard and often were very motivational and increased my faith in myself.

Django blog extra tutorial on slack which gave me many idea and the delete modal code to base my delete modal on.

W3 website for many clarifications of syntax.

Django documentation and bootstrap documentation from which I learnt a great deal.