1. Project Planning.
2. Updates Timeline.
3. Planned Updates.
4. Bugs & Errors.
5. Additional Comments.
6. External Resources.
7. Testing. (see separate folder in /documentation)
8. Deployment
9. Conclusion.

I wanted to create a recipe database long before I started the Code Institute program. As a chef, there are flaws in keeping things like this on paper or in notes on my phone. I want Wikipes to be a hub for users to store their own recipes, and potentially read others. Using user profiles to store specific users own recipes to easily be found on their individual pages. Users that do not log in will still be able to read the recipes but not upload, edit, or delete any recipes on the site.

New Users

A new user enters the site with an intention to either read older recipes or upload their own recipes. If the new user wants to upload one of their own recipes, the user have to navigate to the profile and create their own new profile, then the user will ge given access to the page that is used for uploading a new recipe.

Existing Users

An existing user navigates to the site with intentions to either, read old recipes, upload a new recipe and/or delete or update an existing recipe. The existing user has to be logged in to the site to be able to view their profile which will view the users uploaded recipes that's tied to the userID stored in a database. By this measure the logged in user has full CRUD rights to their own uploaded recipes, but not users with a different userID's.

Admin Users

Admin users using wikipes for a "admin purpose" will have CRUD rights to any recipe to prevent spam and/or content that is not relevant to storing recipes.

User flowchart and project wireframe can be found in /documentation

CRUD Functionality for users

To create a new recipe the loged in user navigates to the "Upload Recipe" page, found in the top right corner. (if the user is not logged in the use will be prompted before being able to upload a new recipe) Here the user will fill in valuable information regarding the recipe. Category, A name, description, ingredients and allergens. If the user wants to edit one of his/hers existing recipes, navigating to your recipes will list your uploaded recipes and give the user an option to edit the recipe, this will also show on the frontpage for the specific recipes tied to the userID.
The steps to delete a recipe is very similar to editing a recipe, the delete option is located next to the edit button on either the "Your recipe" and frontpages.

0.4 2021-05-17

Final Push
Removed comments
Turned off DEBUG
Completed testing
Added overline styling to recipe names.
added text on the frontpage to lead users towards functionality on the page.
Added toast callback with information about the toast button to be re-clickable.
Added allergens button with toast to display information to what which icon means.
removed allergens tooltipped JQuery as it was no longer used.
added footer text, links and color to match the rest of the page
Included a footer

0.3 2021-03-16

Styled webpage globally with button colors, card panels, and label texts.
Editing recipes now looks as intended
Editing recipes now works as intended
Fixed nested IF statements messing with displayin allergn icons only if the previous was checked. Made allergen switches occupy 3 spaces each and center align them on 2 rows
Created edit functionality with conditional if statements to declare wether allergens were toggled in the original recipe.
Created delete functionality to use .remove() on the ObjectId in the database.

0.2 2021-03-15

Created edit page using the upload inserts
Created routing for edit_page
Created submit button for upload recipe
tested allergens toggle and viewed output
Created dictionary to retrieve info from the input fields on upload_page.html
Created variables for allergens to utilize toggles (easier to display on the recipes using if toggle on statement to display icon)
Created routing for upload_page and function to use .insertOne into the
database using the input values from the page.
Created placeholder input field on upload_recipe for testing.
Created routing for login with functions to read hashed password and put user in session
Starting development of login page/route
Finished registration page
Registration function works and uses Werkzeug password hashing
Built the function for new registrated users to be stored in the database
finished registration page layout
Updated index to be able to search categories
Added routing for register page
Added register page
Finished working on frontpage
reset the search function resets the current index, returning user to view all recipes
search function works, filtering the index
Created recipe index in MongoDB to use in the search functionality
Added search route
Added search elements
Added comments for base.html
Added comments for JQuerys in scripts.js
Added ellergens icons with tooltip
Formatted Jinja output for recipes.
Configured .dockerfile for GitPod functionality

0.1 2021-03-14

Created app on heroku and configured Config Vars
Added User Flowchart
Added wireframe
Added Static and Templates folder
Set up app.py with dependencies
set up requirements.txt
set up env.py
added template extentions from base.html
extended base.html to front_page.html
frontpage now renders current recipes from MongoDB

Create cancel button on edit recipe page to redirect user to frontpage
Create If statement on edit page to render all the allergens toggles was on or off before editing
Create function to display users recipes on profile page
Revamp how recipes display on frontpage and profilepage(Add steps)
Implement Search Function
Move flash messages to modal
(focusing on styling instead, if there is time I will try this) Implement User auth

Add more Allergen icons (on frontpage/view all recipes using if x on then
Implement Allergen functions in update/edit recipe to be toggles
Implement Creating of Recipes
Implement Updating Recipes
Implement Deleting Recipes
Implement Functional Registration
Update Project Planning
style buttons to all look the same
Style nav
Style text content
Style brand logo
Style Flash Messages

1. 2021-03-14

Expected Result:

Applying a Jinja for loop in front_page.html would render on-screen in the preview.

Actual Result:

The Jinja for loop renders the HTML element to store the database data from MongoDB but renders the elements empty, regardless of the database that's injected

Resolved Y/N:

Y 2021-03-14

2. 2021-03-15

Expected Result:

using the correct column size would display the search elements and the collapsible element as the same width

Actual Result:

the search and collapsible elements does not align

Resolved Y/N:

Y 2021-03-15

3. 2021-03-15

Expected Result:

Using the implemented python function should render a fully functional and rendered login_page.html, that retrieves data from database to match
user credentials.

Actual Result:

Page does not load and [TO_MANY_REDIRECTS], and heroku returns a HTTP code of 302.

Resolved Y/N:

Y 2021-03-15 - The 302 code indicates redirecting, but the log does not show an endpoint, leading to a probable error in the routing for the page. resolved by editing the /login function with correct indentation.

4. 2021-03-16

Expected Result:

creating CSS code targeting elements in the HTML should change the appearance of the output

Actual Result:

The CSS code does not change the appearance of the HTML, it does work with in-line customization, however.

Resolved Y/N:

Y 2021-03-16 - Due to not having an online preview that could read jinja I had to push the CSS changes to main to display them on the live page. (not best practice)

The commits are somewhat inconsistent, the later ones will use the description to specify the changes in the files. I am using GitHub Desktop and it was simply more effective for me to write in the description.

MaterializeCSS Documentation
StackOverflow
CI Data Centric Modules (MongoDB / Mini Project)

Deployment will be processed trough Heroku and uses automatic deploys trough GitHub connections. Sensitive information is stored in Config Vars hosted on the Heroku backend.

This site is catering to an easy access for users to find and store recipes and should be simple to access.

1. A procfile is created to declare that the application we want to run is a webb application that uses Python and runs trough the app.py python file.
   
2. A requirements.txt file is created using the pip3 freeze command to make sure that Heroku has the required assets to run the application.
   
3. Add the relevant config variables to Herokus Config vars, this makes sure that critical information stays hidden to users that uses the site. Such as ports and IP's used, aswell as the connection to the Database.
   
4. Connect the GitHub repository to the Heroku webb app and enable automatic deployment to keep the live webb app automatically up to date.
   
5. test webb application functionality (read more in testing)

Due to some extensive computer issues, this project has been put under intense time restraints, once again I would like to reach out and thank CI Student Counseling for their understanding and very helpful ways.

Some jinja rendering is basic, and the output for recipes from the database could have been "prettier", but to me, it does its job and works.