Machinery Issue Reporting System

Table of Contents

• Background
• Mission Statement
• Target Audience
• Stakeholder Interviews
  • User Persona
  • User Goals
  • User Stories
  • User Requirements and Expectations
    • Requirements
    • Expectations
  • Site Owners Persona
  • Site Owners Goals
  • Site Owners Stories
  • Site Owners Requirements and Expectations
    • Requirements
    • Expectations
  • Strategy
    • Strategy Outline
    • Strategy Description
      • User
      • Site Owner
  • Wireframes
  • Design Choices
    • Fonts
      • Content
      • Headings
    • Colours
    • Images
  • Structure
    • Site Structure
    • Data Schema
    • Models
    • Forms
  • Branches
  • Features
    • Existing Features
    • Features to be implemented
  • Technologies used
    • Languages
    • Libraries and Frameworks
    • Tools
  • Testing
    • Accessibility
    • UX Testing
    • Manual Testing
    • Code Validation
    • Bugs
    • Unfixed Bugs
  • Deployment
    • Local Deployment
    • Deployment via Heroku
  • Credits
  • My Thoughts

Background

With the restrictions in place within teaching in the Irish Universities due to the Coronavirus pandemic, the improved organisation of working methods to reduce contact with staff and students over more trivial tasks have to be looked at. With this in mind, TU Dublin's engineering department has been looking to implement a machinery issue reporting system for the many machines to which the students have access. Currently, the engineering department is using a manual process where students write into a diary, where unnecessary physical touchpoints are created, or send an email where there is potential for loss of information to happen. They are looking to create an automated system to improve the procedure for all stakeholders.

Mission Statement

Provide a fully automated, easily used and aesthetically pleasing machinery issue reporting system for TU Dublin.

Target Audience

The target audience consists of approximately 150 students, both full time and part-time. The students are of a similar educational standard due to the course entry requirements but there is a selection that has extra educational needs so this needs to be addressed with accessibility built into the application.

There are three members of staff, one technician and two lecturers.

Stakeholder Interviews

I carried out short interviews with both a selection of staff and students that this project will affect. All people interviewed will be Users, however for an easier view of the breakdown of requirements, I have split the results into students and staff.

Student Persona

These are the details of the students interviewed. Two criteria were taken into consideration when selecting appropriate candidates for interviews. Firstly that they are either a part-time or full-time student of TU Dublin, and also that the course they are enrolled on is within the engineering department.

Student Goals

From the resulting interviews, the user goals have been defined:

• See what defects or issues have been reported
• See what defects or issues I have reported
• Clear display in a landing page
• Clear navigation process
• Ability to use the system on a mobile phone

Student Stories

• As a student, I want to have a clear and defined landing page
• As a student, I want to be able to report aa issue on a machine
• As a student, I want to see any issues that I have reported
• As a student, I want to see the machine's name and description
• As a student, I want to see if there are any issues already reported on a machine
• As a student, I want to know this is a TU Dublin application

Student Requirements and Expectations

Requirements

• Simple and well laid out
• Visually appealing
• TU Dublin colour pallet
• Clean and modern looking
• Easy to report an issue in just a few clicks
• Responsive design is required (Mobile first) as users may be viewing the site on Mobile, Tablet or Desktop

Expectations

• I expect to use the application on any size device without the experience effected
• I expect that when I report an issue I can see that it has been logged
• I expect to be able to report issues on multiple machines

Staff Persona

These are the details of the staff interviewed. The staff members will all be teaching in TU Dublin, within the engineering department. There are three staff that fit this category, two lecturers and one technician. Unfortunately, I was only able to interview one lecturer.

Staff Goals

From the resulting interview, the site owner's goals have been defined:

• Create a machine with a short description
• Delete a machine when required
• Edit a machine's details when required
• See any issues that have been reported
• Change the status of a machine with an issue
• Delete an issue when it has been rectified
• Clear navigation process
• Visually clear that it is a TU Dublin application

Staff Stories

• As a site owner, I want to see any issues with machines that have been reported
• As a site owner, I want to delete an issue when it is rectified
• As a site owner, I want to provide a description of the machine for the user
• As a site owner, I want to provide an image of the machine for the user
• As a site owner, I want to manage the users

Staff Requirements and Expectations

Requirements

• A higher level account than a student
• Different sections in the login to manage the different tasks
• Create, Read, Update and Delete functionality
• Simple and well laid out
• Visually appealing
• TU Dublin colour pallet
• Clean and modern looking

Expectations

• I expect to quickly manage users
• I expect to quickly manage machines
• I expect to quickly delete issues on machines when required
• I expect to know this application is associated with TU Dublin

Strategy

Strategy Outline

The items are graded in a 0 - 5 system in both importance and feasibility as per the grading system below.

The outcome is calculated by combining the scores from the Importance and Feasibility ratings. This then gives a final strategy rating of what items and where to focus on.

Strategy Description

Student

Site Owner

  Back to Top
 

Wireframes

Originally, the design was that the user immediately was bought to the login page, however, following the agile process, I received feedback from the client that this was no longer the case and they requested a landing page. This is the wireframe for this page.

Login screens and edit information pages will be a very simple look with an image in the background and the form centred on all screen sizes.

The other screens, dashboard and current issues screens will display the items in a simple grid display to keep the pages uniform.

The individual machine page will be simple and will hold the title, description, image and the report an issue form.

The manage users page will be displayed as a simple table

  Back to Top
 

Design Choices

Because this project is being created for TU Dublin, and all the user's requirements include the need for it to be within keeping of the existing designs, the following design choices will be based on this.

Fonts

The font that TU Dublin currently uses is Visuelt-Regular, this, however, is a font that would have to be bought and not something that is going to happen with this project. Because of this, I have picked a font from Google Fonts that is as close as I can get to keep the user experience as close as possible.

Content

Using a font weight of 300, Roboto

Headings

Using a font-weight of 900 and styled to be uppercase, Lato

Colours

The colours will be set variables within the CSS file using the names in the table below.

To keep the user experience consistent, the colour red will be used for deletion, orange for editing and green for the creation or to cancel an action.

The colours all pass the WebAIM tests and the results can be seen below.

• Blue
• Orange
• Red
• Green

Structure

App Flow

The basic template views displays have been planned out using Lucid.

Data Schema

The data schema was created using dbdiagram.

Models

Machine

Issues

User

This will be initally built at the start of the app as an empty model, giving me the oportunity to adapt the Django User fields if required.

  Back to Top
 

Branches

The majority of my code was written using branches in Gitpod. As I was new to this process, occasionally I was over-eager and pushed my changes straight to the main branch however this is in a minority as can be seen through the commit history. In a normal project, I would have deleted all my branches, except for the default main, however, I have chosen to keep four as examples of the process.

• Branch 1 created to work on Issue #99
• Branch 2 created to work on Issue #94
• Branch 3 created to work on Issue #91
• Branch 4 created to work on Issue #88

  Back to Top
 

Features

Existing Features

Spin Loader

The spin loader was generated using loading.io and is displayed on all pages until the document is loaded. When it has, it fades away to show the content of the application.

Navbar

The navbar is fully responsive and has been created to have different links available, depending on if the user is signed in or not.

While the user has not been authenticated or signed in to the application, on display are the Login and Signup links only. The university logo at this point acts as a link back to the landing page.
 

The same applies to the links for the mobile view, however, the styling is adjusted to be responsive. A hamburger menu is used to slide from the right side of the screen. The location of the hamburger in the top right corner of the screen is to suit the 90% majority of right-handed people.
 

For a basic user, once signed in the options on the navbar change to show:

• University name - links to the dashboard
• Dashboard - links to the dashboard
• Issues - links to the issues page
• Profile - links to the edit profile page
• Logout - links to the logout page
• Machine search - opens machine name search bar

The orange underline of the link shows the active page to the user, also a hover effect of changing colour on the text adds to the user experience. The search feature on the mobile layout moves in and leaves the hamburger on the edge, to improve user experience as the hamburger is more likely to be used more often.
 

For a staff member, once signed in the options on the navbar change to add extra dropdowns:

• University name - links to the dashboard
• Dashboard
  • View Machines - links to the dashboard
  • Create Machine - links to the create a machine page
• Issues - links to the issues page
• Profile
  • Edit Profile - links to the edit profile page
  • All Users - links to the all users page
• Logout - links to the logout page
• Machine search - opens machine name search bar

The search feature in the navbar is available to both staff and basic users. It searches the machine database based on the machine name and this is prompted through the placeholder text. There is also a fade in and out on this element to improve the experience.

Footer

The footer comprises two elements, the university name with auto increment copyright year and links to their social accounts. The layout changes slightly depending on screen size, the social links are moved to a fade in and out container on the smaller screen sizes. This container can fade out when either the user scrolls back up the screen, or if they click elsewhere in the body of the application.

Messages

Messages are displayed for continual feedback to the user on their interactions and follow the same layout for both mobile and desktop designs. These interactions include:

• Sign in
• Logout
• Create a machine
• Update a machine
• Delete a machine
• Create an issue
• Delete an issue
• Edit profile
• Edit staff status of a user

Homepage

The home page is a simple set-up with two elements, the hero image and the information cards.

The hero image of a machine is fitting with the context of the project and the colour scheme also suits perfectly with the universities pallet. The text container is consistent with TU Dublin's site so it helps with the staff user story of needing to know that it is associated with the university.

The information cards give a brief outline of the reasoning behind the development of the application. The information is helped by the use of icons and is also responsive by stacking on top of each other for smaller devices.

• Desktop

• Mobile

Dashboard

The dashboard includes a personal welcome to the user and introduces them to the dashboard. The machines that are created by the staff members are displayed here with the view changing depending on authentication level.

If the user is logged in as a staff member, the delete and edit buttons will be displayed if the user is a basic user, the card with the image and title are displayed. The image and the title also act as a link that navigates to the detailed view of the machine.

If an issue has been raised on one of the machines, then a warning note also shows on the card. The cards are ordered firstly by if there are any issues reported, then in alphabetical order.

• Staff view

• Basic User view

To keep the display of the machine cards compact, there is pagination built into the application. Only six items will be displayed on the screen at one time, if there is more the next and previous buttons will navigate to these items.

There is also notification to the users if there are no machines currently created. This provides a short explination and a shortcut link to create a new machine.

Machine Details

The machine details page shows the detailed description of the provided by a staff member when the machine was created. This is also where a user can create an issue using the Report an Issue button. This opens the form in the way of a modal with the machine name populated. The Cancel button closes the modal, and the submit button add the issue to the database and gives the user a message of confirmation.

Issues

At the very top of the issues page, there is a search bar, that works in the very same way as the machines name search, only it searches through the descriptions in the issues.

The issues page, like the dashboard, is made up of a series of issue cards order by the date that they were created on. These contain:

• The machine name
• The username of the user that created it
• Timestamp of when it was created
• Description left by the user
• For staff members only, the Delete button.
   
• Staff view

• Basic view

Only visible to staff members is the delete button when it is clicked, a defensive model pops up to ensure that the user is sure that they would like to delete the issue, on the confirmation, the issue is deleted from the database and a message is relayed to the user.

On deletion of the last issue or, if there have been none created yet, there is a prompt to the user so they are aware of this.

All Users

This page is only available to the staff users of the application. At the top of the page, there is a search bar that can be used to search for the user's usernames, working in the same way as the previously detailed searches in the application. The main content consists of a table populated with a full list of all registered users and displays some of their details:

• Username
• First name
• Last name
• Staff status

Each user also has an edit button associated with it and a delete button. The edit button allows a staff member to give another user full accessibility to the application. On clicking update, a message is displayed showing that the staff status has been changed for that particular user.

The delete button opens up a model for a defensive confirmation that this is the action wanted to be carried out. On deletion, the user is removed from the database.

Edit Profile

The edit profile page is available to all user levels. This page gives the user the ability to adjust their details:

• Username
• Email
• First name
• Last name

The update button updates the database and gives the user a message to confirm the profile was updated, and the cancel button returns to the dashboard.

Authentication

The authentication process for the application has three parts.

• Sign Up
• Sign In
• Log out

Sign Up

The signup process requests three required fields from the user:

• Username
• Password
• Password confirmation

If the user enters a username that already exists, or the two password fields do not match, then error messages are prompted to the user.

If all the fields are correctly populated and the Sign-Up button is clicked the user is navigated to the dashboard and a message is displayed to tell the user that they are successfully signed in. If the user has already registered and is looking to sign in then there is a handy link to the correct page in the text above the form.

Sign In

The sign-in form requires only two fields to be entered.

• Username
• Password

Like the signup form, there are messages displayed if incorrect or non-matching data is entered. And a link to the signup page if the user has not already done so. The sign-in button, with correct credentials, directs the user to the dashboard with a successfully logged in message.

Log out

This is the simplest of the three authentication form in the application. a simple choice of yes or no if the user would like to sign out. The yes button directs the user to the homepage with a message letting them know they have successfully logged out, and the no button directs the user back to the dashboard page.

Buttons

The buttons on the application, for consistency, have the same design, with the only difference being the colours.

• Green is for confirming an update or creating

• Red is for deletion

• Orange is for editing or cancelling an action

All buttons also have the same hover effect to keep the user experience consistant.

Features to be Implemented

• Multiple filters on the issues filter.
  • By filtering by machine name and description, this would allow better flexibility for the user to narrow the search down and speed up the process of searching.
• Booking system.
  • By adding a booking system into this application, the users would easily see the availability of machines. If there were current issues on the machine, it would be unavailable for use.
• Email or push notification
  • A notification to the staff members that an issue has been created would speed up the process as they would not have to log in each time to see the status of machines
• Automatic logout after a set period of idle time
  • A security addition if a staff user forgets to log out themselves out, the application does it automatically so another user cannot have access.

  Back to Top
 

Technologies used

Languages

Libraries and Frameworks

Tools

Testing

Accessibility

With accessibility included as a user goal, I have tested the pages of the application using WAVE to ensure there are no errors. The results can be seen by following the links below. Each test shows that there are 2 contrast errors, these errors are where WAVE is picking up screen reader only spans and suggesting that they have a poor ratio between the back and foreground colours. These two elements are not visible to the user as they hold the bootstrap class of sr-only, so the errors here can be ignored.

• Homepage accessibility results

• Dashboard accessibility results

• Individual Machine accessibility results

• Create Machine accessibility results

• Edit Machine accessibility results

• All Users accessibility results

• Issues accessibility results

UX Testing

Staff Member

Student User

  Back to Top
 

Manual Testing

Manual testing of the project was a continual process to ensure that all was working as expected. Items were fixed as the project was being carried out to ensure not to have a huge workload of fixes at the end. Manual testing and checks include:

• Loading Spinner

  • Displays on all pages while the content is loading
  • Centered in the page
  • Fade effect to display none

• Navbar

  • All links navigate to correct endpoint
  • All hover and focus effects are correct
  • Active link underlined
  • Different views depending on staff status and authentication
  • Search bar fades out when the body is clicked
  • Accessibility is correct
  • Responsiveness

• Footer

  • All links navigate to correct endpoint
  • All hover and focus effects are correct
  • External links open in a new tab
  • Accessibility is correct
  • Responsiveness

• HomePage

  • Text is clear and easily read
  • Image is shown and colours are complementary to the site
  • Information boxes clear and free of spelling mistakes
  • Responsiveness

• Login and Signup

  • Form is clear
  • Links navigate to the appropriate page
  • Hover and focus effect on the button
  • Background image clear visible
  • Form completes its task correctly

• Logout

  • Options are clear
  • Hover and focus effect on the buttons
  • No button returns to the dashboard
  • Yes button logs the user out and returns to the homepage
  • Message displayed to the user on the homepage when logged out

• Dashboard

  • Username is displayed in the page title
  • Content displayed if there are no machines created
  • Create machine button to link to the correct page
  • Hover and focus effect on the buttons
  • Machine cards to display edit and delete buttons to staff users only
  • Delete button opens confirmation modal
  • Confirmation modal delete button deletes the machine
  • Confirmation modal cancel button returns to the dashboard
  • Image and machine name act as a link to the machine details view
  • Current issues banner displayed when an issue is created against the machine
  • Pagination occurs when there are more than 6 items
  • Responsiveness

• Create Machine

  • Only accessible by a staff user
  • Responsiveness
  • Required fields must be completed
  • File upload works as expected
  • Hover and focus effect on the buttons
  • Cancel button returns to the dashboard
  • Submit button saves the machine, redirects and displays it on the dashboard

• Issues

  • Content displayed if there are no issues
  • Pagination occurs when there are more than 6 items
  • Username, date and description displayed in the issue card
  • Hover and focus effect on the buttons
  • Delete button only visible to a staff user
  • Delete button opens confirmation modal
  • Confirmation modal delete button deletes the issue
  • Confirmation modal cancel button returns to the issues page
  • Search bar filters the issues by description
  • Search bar X button clears the filters and displays all issues

• Edit Profile

  • Responsiveness
  • Required fields must be completed
  • Hover and focus effect on the buttons
  • Cancel button returns to the dashboard
  • Update button saves the profile changes, redirects to the dashboard and displays a message to the user confirming a change

• All Users

  • Only accessible by a staff user
  • Responsiveness
  • Hover and focus effect on the buttons
  • Delete button opens confirmation modal
  • Confirmation modal delete button deletes the user
  • Confirmation modal cancel button returns to the all users page
  • Edit button navigates to the edit staff status page
  • Correct staff icon displayed in the table
  • Search bar filters the users by username
  • Search bar X button clears the filters and displays all users

• Edit Staff Status

  • Username is displayed in the text content
  • Checkbox is either ticked or not depending on the current status
  • Hover and focus effect on the buttons
  • Update button saves the changes, redirects to the all users page and displays a message for confirmation
  • Cancel button navigates back to the all users page with no changes

Code Validation

HTML

The HTML code within the application has been validated by W3C Markup Validation Service. Pages were put through the validator seperatly and the results can be seen below.

• Homepage HTML validation results

• Dashboard HTML validation results

• Individual Machine HTML validation results

• Create Machine HTML validation results

• Edit Machine HTML validation results

• All Users HTML validation results

• Issues HTML validation results

• Signup HTML validation results

• Sign in HTML validation results

• Log out HTML validation results

CSS

The CSS code within the application has been validated by W3C CSS Validation Service, and the results can be seen below.

• CSS validation results

JS

The JavaScript and JQuery code within the application has been validated by JSHint, and the results can be seen below.

• JS validation results

Python

The Python code within the application has been validated by PEP* Validation Service. Files were put through the validator separately and the results can be seen below.

• issue_reporting project

  • settings.py validation results
  • urls.py validation results

• accounts app

  • forms.py validation results
  • test_forms.py validation results
  • views.py validation results
  • test_views.py validation results
  • urls.py validation results

• home app

  • urls.py validation results
  • views.py validation results
  • test_views.py validation results

• issue app

  • admin.py validation results
  • forms.py validation results
  • models.py validation results
  • views.py validation results
  • urls.py validation results
  • test_models.py validation results
  • test_views.py validation results

Bugs

1. Issue #36 - Delete machine modal

   • The incorrect title was entered on the modal, hot-fix changed this.

2. Issue #34 - Create machine form styling

   • Styling was correct and made to be responsive

3. Issue #46 - Cancel button on Create Machine page

   • The cancel button was not directed back to the correct dashboard page, hot-fix to the URL on the cancel href fixed the bug

4. Issue #56 - Create User error

   • After attempting to create a custom user model, I reverted to the out of the box Django authentication system. This caused problems with my user's and superusers not being recognised. This problem was solved by deleting my Postgres database in Heroku, migrating and then creating a new superuser, then a basic user

5. Issue #68 - Create new machine layout

   • When a user was logged in as a staff member, there was a create a machine card as part of the dashboard. This threw out the look of the page with the pagination set to 6. 7 cards were shown to the staff user and the styling looked very poor. The decision was made to add create a new machine to the navbar to keep the pagination looking correct

6. Issue #78 - Footer positioning

   • The footer was set to position fixed to the bottom of the application. This created a visual problem as it covered content and I felt that it was in the way of more important content. The decision was made to make use of flexbox to ensure it is always sitting at the bottom of the content of the application

7. Issue #91 - Close social links container

   • The social links container was only able to be closed by clicking on the links button. This was a poor user experience so a small bit of JQuery was written to fade it away if the user scrolls or taps the body of the application

8. Issue #94 - Mobile slide nav home link

   • The logo link on the slide-out nav on mobile view was directed to the dashboard before a user has been authenticated. A quick if authenticated statement to change the link property was a quick fix

9. Issue #112 - Create new machine page

   • This was the second bug relating to the layout of the create machine form. The root cause of this bug was the height property of the image container. By changing it to min-height: 100vh; the form's styling is perfect.

10. Issue #96 - Footer text alignment

    • The footer text was not aligned to the middle of the screen because the social links were pushing it to the left slightly. By setting the position property of the social links to relative, the text could be centred properly.

11. Issue #104 - Deployment error

    • I had issues trying to create my global variables and rendering them to the templates. Eventually, by reading the Django docs, I discovered that instead of just importing them into the template, I had to add them in via an extra_context dictionary.

12. Issue #121 - Extra content not showing on allauth views

    • Once I had the extra_context dictionary rendering to the templates, I found that it did not apply to the allauth templates. By creating my own views that pointed to the allauth templates, I could render out my extra_context. However, this did lead to an unfixed bug which I go into detail about in the next section.

13. Issue #142 - Images not uploading to Cloudinary

    • When the user created a machine and attempted to upload an image, the form was not talking to Cloudinary and the placeholder image was always displayed. The inclusion of the cloudinary tag at the top of the file and enctype to the form fixed this bug.

    {% load cloudinary %}
    
    <form method="post" enctype="multipart/form-data">

14. Issue #145 - Messages overlapping text

    • The messages given to the user when an action was completed, i.e. delete or create a machine were overlapping the content of the application. I created a spacer that acted as a placeholder for the messages so there was no content behind it

15. Issue #151 - Links on on allauth pages not working

    • The signin text link on the signup page and signup text link on the signin page were still navigating to the out of the box Django templates. Hot-fix to the URL sorted this bug

16. Issue #90 - Images not showing on deployed site

    • Neither of the background images were showing on the deployed site, this was rectified by adding the cloudinary URL directly into the CSS file instead of using an absolute file path

17. Issue #183 - Social link hover on mobile

    • The social links in hover and focus state did not have any styling, a hot-fix with the project's blue was added.

Unfixed Bugs

I have created my own custom views for the Django authentication pages, login, signup and logout to be able to add my global variables for ease of maintenance. The logout view has no issues, however where there is a form with inputs a bug arises. If a user enters incorrect data, the form's action redirects to the default account/login or account/signup page depending on which is submitted. This then does not have any of the global variables rendered as extra_context and the university name in both the header and footer, along with the URLs for the social links are blank. Changing the action of the form breaks the set-up of Django auth and does not allow a user to login or sign-up at all.

  Back to Top
 

Deployment

This project was created using GitHub and the code was written using Gitpod. Branches were created and after committing to the branch it was pushed up to the repository. This project is also deployed to Heroku with Heroku deployment set to Enable Automatic Deploys. This means that every time that the repository was pushed to, Heroku was updated also.

The live link to the application can be found here

Local Deployment

As Gitpod was the IDE that was used to create the project, the following local deployment steps are specific to Gitpod.

Cloudinary

• Visit Cloudinary by following this link
• Click on the Sign Up For Free button
• When the account is created, you should see the API Environment variable, we will need this for a later process.

GitHub

• Visit Github by following this link
• Create an account or log in

Forking

• Navigate to the repository by following this link
• Click on the Fork button in the top right of the screen

GitHub Desktop

• Navigate to the repository by following this link
• Click on the Code button above the file list
• Select Open with GitHub Desktop

Set up your Workspace

When you have your version of the original repository,

• In the terminal run

pip3 install -r requirements.txt

• In the root directory create a file called env.py and add the following content, the content of these, must match the Config Vars in the Heroku deployment section

import os

os.environ['DATABASE_URL'] = "FROM HEROKU DEPLOYMENT SECTION, DATABASE_URL CONFIG VAR"
os.environ['SECRET_KEY'] = "FROM HEROKU DEPLOYMENT SECTION SECRET_KEY CONFIG VAR"
os.environ['CLOUDINARY_URL'] = "API ENVIRONMENT VARIABLE REMOVE 'CLOUDINARY_URL=' FROM BEGINING"
os.environ['DEVELOP'] = '1'


os.environ['UNIVERSITY_NAME'] = "ADD CONTENT HERE"
os.environ['FACEBOOK_LINK'] = "ADD CONTENT HERE"
os.environ['INSTAGRAM_LINK'] = "ADD CONTENT HERE"
os.environ['TWITTER_LINK'] = "ADD CONTENT HERE"
os.environ['MACHINE_CARDS_CURRENT_ISSUE_TEXT'] = "ADD CONTENT HERE"
os.environ['NO_ISSUES_MODAL_TITLE'] = "ADD CONTENT HERE"
os.environ['NO_ISSUES_TEXT'] = "ADD CONTENT HERE"

• Add the env.py file to the .gitignore file to ensure that its contents are not made public

• Migrate the database models with the following command in the terminal

python3 manage.py migrate

• Create a superuser and set up the credentials with the following command

python3 manage.py createsuperuser

• Run the application locally with the command

python3 manage.py runserver

• To access the admin page using the superuser details just created, add /admin to the end of the URL.

Deployment via Heroku

• Visit heroku.com
• Create a new account or sign in
• From the dashboard, select New and then Create new app
• Enter an individual app name into the text box, select a region from the dropdown and then press Create app
• A Heroku app has now been created and the Deploy tab is opened.
• Open the Resources tab and in the search bar for Add-ons type Postgres
• Select Heroku Postgres, on the popup, ensure the dropdown is set to Hobby Dev - Free and then Submit Order Form
• Open the Settings tab and then click on the Reveal Config Vars button and the database_url should be populated.
• Fill out the rest of the config vars with the content of the table below by filling out the Key and Value and clicking on Add for each entry

• In the buildpacks section of the settings tab, click on Add Buildpack, select python and then save changes
• Open the Deploy tab
• In the deployment method section, select GitHub and confirm the connection.
• Enter the repo-name into the text box and click Search. When the correct repo appears below, click Connect
• Return to the Gitpod workspace and in the root directory create a file called Procfile
• In the Procfile enter the following line including your project name

web: gunicorn YOUR_PROJECT_NAME.wsgi

• Add and commit to GitHub

git add .
git commit -m "commit message goes here"
git push

• Add your Heroku app URL to ALLOWED_HOSTS in your settings.py file

ALLOWED_HOSTS = ['YOUR_PROJECT_NAME.herokuapp.com', 'localhost']

• Return to Heroku
• In the Automatic deploys section, click Enable Automatic Deploys. This updates every time GitHub code is pushed
• To complete the process click on the Deploy Brach button in the Manual deploy section, this will take a few seconds to complete while Heroku builds the app
• A message will appear informing you that the app was successfully deployed and a View button will bring you to the live site

  Back to Top
 

Credits

• Code Institute for the template
• Simen Daehlin for advice and direction and continual support
• CodingEntrepreneurs for help on Django and testing
• Codemy.com for help on Django
• For gentle helping nudges, the Code Institute tutors
• For testing and feedback, my 'testing focus group' (they know who they are!)

  Back to Top
 

My Thoughts

I found this project a huge step up from the previous projects that I have created so far. It is my first all-around project incorporating both front and back end work. I feel that I've created a solid project that meets the requirements of TU Dublin, even if there are a few extra features that I will implement at a later date.

I initially found working with Django, like trying to run through a concrete wall. However the more I read the documentation it eventually started to sink in. One regret that I do have with the project is not splitting up the issue app into two smaller ones, issue and machine. The way that it is at the moment, it is a monster. I did attempt to split it apart however it was towards the end of my timeline and I was losing too much time doing so.

Another part of the project I still don't feel completely comfortable with is Django testing. I have made my best effort at creating tests but I think that I have a very long way to go in becoming proficient at this, a change in mindset and thinking procedure could be on the cards here.

Overall, even though there were tough moments, another enjoyable project.

  Back to Top