701-t4 / flatshare Goto Github PK

Is your feature request related to a problem? Please describe.

Our application should have the correct metadata tags so it displays nicely in embeds, has a proper browser tab title, etc.

Describe the solution you'd like

Update the public index.html file, manifest file etc to be representative of the app. When posted on twitter/discord etc, our website should embed correctly with a nice image and description (see https://ogp.me/).

Notes

This is not urgent, and not part of the initial milestone.

Describe the bug
After sigint in the start:dev root script, the applications don't properly close. May be a windows issue.

To Reproduce
Steps to reproduce the behavior:

1. Run start:dev
2. Ctrl + C to kill
3. Ports are still in use (try to start:dev again)

Expected behavior
Killing the script should kill all processes (hence freeing the ports).

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: windows

Proposed Fix

• Add a script that will just kill the processes on port 3000 and 4200
• Investigate other fixes (i.e. sigint handlers)

Is your feature request related to a problem? Please describe.

Authenticated users need a sort of 'home screen' to take them to different parts of the app.

Describe the solution you'd like

• A design of a dashboard on Figma
• The dashboard implemented in React

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
It is frustrating to have to install mongodb before being able to run the app or do any work. We should have some way for developers to be able to get started without having to install anything.

Describe the solution you'd like
Ideally we can find some free online hosting for mongodb.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.

A sharing link is helpful to quickly get people to join flats, even if they do not have an account yet.

Describe the solution you'd like

Users in the flat can get a sharing link. People who go to the URL of that sharing link will be added to the flat.

Some (not finalized) specs

Frontend

• Dashboard contains a button somewhere to add get a sharing link (maybe opens a small popup)
• Sharing link is easily copied to clipboard (i.e. via a button)
• Sharing link contains the app URL with a query parameter at the end with the code
  • i.e. localhost:3000?join=the_code
• When going to that link:
  • If they are logged in, they will be added to that flat IF they are not in a flat already
  • If they are logged in AND already in a flat, then a modal should pop up saying they can't join another flat until leaving the current one.
  • If they are not logged in, the code should be persisted somehow (i.e. local storage). Once they are logged in, the app can read the persisted data and then follow through with the two options above.

Backend

• An endpoint to get the sharing code part of the URL that will be generated by the frontend.
  • Presumably this sharing code will be associated with the flat when it is generated.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Describe the bug
Currently the endpoint /api/v1/house returns an empty body if the user doesn't have a house assigned. Instead we should return 404 status.

To Reproduce

Steps to reproduce the behavior:

1. call /api/v1/house with a user that doesn't have a house assigned
2. the body will be empty

Expected behavior
http 404 should be returned

Additional context

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. bug, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.

Now that #28 adds the typings for our API, we should be able to use this in order to provide type hints for our useApi hook.

Describe the solution you'd like

A hook that provides autocomplete and type hinting for making api requests. It should be able to know what path params there are, and the format of message body. Since this is likely going to be a best-effort type of system, an alternative untyped hook should also be available in case there are issues with the typings.

Describe alternatives you've considered

We could just not do this and rely on developers to manually type things themselves.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.

If we want to use NextUI we need to set up its context and themes.

Describe the solution you'd like

• Add the NextUI context
• Create the theme so it can be easily edited or added to in the future

Additional context

• This guide may help: https://nextui.org/docs/theme/customize-theme

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.

Bill splitting is an essential part of a flat sharing application

Describe the solution you'd like

WIP - we will need to have a meeting to spec this task out.

Potential requirements:

• Bills for electricity, internet, Rent etc.
• Ability to add bills and split them among flat members
• Ability to mark your own bills as paid
• Keeping track of how much everyone owes etc

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
Task splitting would be a nice part of the app to complete.

Describe the solution you'd like
Here are the current specifications:

• Add a new PRIVATE page - /tasks
• Tasks card on dashboard should navigate to this.
• This page should list all the tasks in the flat:
  • Recommend using cards similar to those on dashboard page.
  • Card should list task name, description, completed checkbox.
  • Task ordering:
    • Incomplete assigned to user
    • Other incomplete tasks
    • Complete tasks assigned to user
    • Other complete tasks
• Users can click on the card to open a details view
  • Can be on /tasks/{id}
  • React router to handle this - react hook to get path params to then fetch that id from the database.
  • Should have the ability to edit the task name, description, or pool of assigned people if you are the OWNER.
  • Should have the ability to delete the task if you are the OWNER.
• Top part of the page with button to return to dashboard and button to add a new task. This can be done on a new page or modal.
  • New task should have the following:
    • Name,
    • Description,
    • Table of people who can be assigned to the task (i.e. pool of people). This table should list all people in the house with checkmarks to say whether they are assignable to this task.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
The backend code should be uniform and have good style guidelines.

Describe the solution you'd like
Setup ESLint rules and make husky fail the commit if any rules generate warnings.
You can use common sense to select what rules should be enabled. Make sure that you have added rules specifically for nest and for typescript.

Describe alternatives you've considered
We currently have prettier but it does not enforce style

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
Our application will likely require 3rd party services to handle things that we probably shouldn't (i.e. auth).

Describe the solution you'd like
Firebase setup with auth and hosting enabled. Firebase added to the project. Members have access to the firebase project.

Discussion
Do we want to use another hosting provider or another auth provider? Firebase auth and hosting will be free for us, and its very easy to use, which is why I've suggested it, but open to new ideas.

Is your feature request related to a problem? Please describe.
Often we want to use components like toasts to respond to user actions, to acknowledge that something is happened. It would be useful to have an easy-to-use component API to allow for this.

Describe the solution you'd like
A toast/corner alert, callable via a easy function or hook.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Specification

• Users can add notes (essentially key-value pairs)
• Users can select for the values to either secret or visible (secret can just mean the text becomes '●●●●●')
• Users can delete notes
• There should be a card-like component essentially warning users that very secret information (i.e. important passwords) should not be stored on here.
• Should only be visible by people in the flat

Back-End Specification

• Introduce new “notes” table with the following structure:
  • name
  • value
  • type (enum with ‘plain’, ‘secret’, ‘wifi’)
• Add the following endpoints:
  • GET /house/notes
    • Returns all notes in the house
  • POST /house/notes
    • Create a new note
  • DELETE /house/note/{id}
    • Delete a note
  • PUT /house/note/{id}
    • Update a note

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
It is frustrating when getting started with the project to manage the environment files. The back-end currently manages the .env files using templates while the front end relies on overriding the default config.

Describe the solution you'd like
We should make the back-end use the same logic as the front-end so that the code works by default without any additional config.
Ideally we also move the .env files to the root directory and merge the front-end and back-end env files.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
Implement database

Describe the solution you'd like
Implement mongodb (most likely using mongoose) into the back-end code

Describe alternatives you've considered
We considered postgresql but decided against it due to the short time available to work on this project

Additional context
https://www.mongodb.com/

Is your feature request related to a problem? Please describe.

We need to authenticate users to show them the relevant information.

Acceptance Criteria

• Add firebase to the project FE
• Add a Sign in with google button, possibly using this: (https://www.npmjs.com/package/react-firebaseui)
• There should be a high up React context that stores the user object.
  • A custom hook like useAuth() should give access to the current user, using this context.

Describe the solution you'd like

Firebase authentication - sign in with google

Describe alternatives you've considered

Auth0 - Less familiar and would be more effort to setup.
Our own Auth system - Significantly more effort, increases security risk, not as convenient for users.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
We do not currently have a way to find a users name without the user actively providing their token. This will become an issue when we want to display the other members in the same house.

Describe the solution you'd like
When creating a user, we should also save their name into the database. We will also have to update endpoints that return the user to also include the name, as it may diverge from the firebase name.

Describe alternatives you've considered
We could alternatively save their firebase token but this would require significant stripping to not cause security issues. It will be better to simply save info as we need it.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
Currently the frontend is not built and tested on CICD.

Describe the solution you'd like
Add CICD steps to build and test the frontend on a pull request to the existing workflow file.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
Once we start getting more complicated dependencies we need to make sure our app is quick and easy to set up a development environment.

Describe the solution you'd like
We should use docker to automatically create the environment needed for development

Describe alternatives you've considered
alternatively we could provide instructions for setting up everything manually. This would quickly get out of hand as we add dependencies and need to maintain instructions for many operating systems.

Describe the bug
After logging in you are redirected to /home after a refresh you are directed back to /landing and must log in again to access /home

To Reproduce

Steps to reproduce the behavior:

1. Go to main landing page
2. Click on log in
3. Log in
4. Once the home page has loaded: refresh
5. It will now go back to the landing page
6. You can no longer navigate to /home

Expected behavior
The user should stay on /home if they navigate back to /landing the sign in button should either immediately redirect to /home instead of auth or should change the text to Go to App or something similar.

Desktop (please complete the following information):

• OS: Ubuntu 20.04.4 LTS
• Browser: firefox
• Version 97.0.2

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. bug, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
There are quite a lot of project specific steps missing on the PR and issue templates that should be added.

Describe the solution you'd like
Checklists should be extended based off of items on GitHub checklist. Not all items on there will be applicable so use discretion.

Issue templates should have checklists added

Is your feature request related to a problem? Please describe.
This replaces the previous passwords page. It has slightly larger scope. The intent is to allow flatmates to share general information.

Describe the solution you'd like

Front-End Specification

• Add a new PRIVATE page in AUTHENTICATED ROUTES - /notes
• Design up to you, basically just a list of notes with names that can be opened to a wider description
  • Suggestion: maybe a grid of post-it note type squares that show a name, that can be clicked on to open up a modal.
• Modal contains detailed information about the note:
  • Different notes have different types, so you will need to render a different component based on the type given.
  • “Plain” for presenting a plain note.
  • “Secret” for presenting the note but with password-style text that can be displayed by pushing a button.
  • “Wifi” would be the same as secret, but add a button that displays a QR code of the password.
  • Top of modal should have an edit option that makes the fields editable.
  • Anyone in the house can edit these values.
• Top of the page to contain a “return to dashboard” button and a create new note option:
  • Create a note will need:
    • Name
    • Type (normal, secret, wifi)
    • Description
  • For secret types, a disclaimer should be shown that secrets aren’t stored securely, so the users is aware that they are disclosing all information on the document publically.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
There is currently no way to logout on the frontend.

Describe the solution you'd like
there should be a route /logout that removes the token from the cache. Links to the logout screen should be added when appropriate.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.

Users need to be able to add and join houses.

Describe the solution you'd like

Once a user is logged in, they need to be able to create or join a house. Detailed specification for the entire milestone is on this page.

For this task, the specs are as follows (not yet final):

Frontend

• New users will be shown a screen where they can either create or join a house
  • Joining a house will require a code
  • Creating a house will ask the user for some basic information, such as a name
• Users in a house will be directed to the dashboard for that house
  • This task doesn't require the dashboard to be implemented, just that they are redirected to the page

Screens

• Page to create new or join house
• Page to create a new flat

Backend

• New users are created in the database with the Firebase (#40)
  • Please modify the guard to create a new user in the db if the auth is correct but user doesn't exist. See comments on issue #40 and related PR #51 for details
• Endpoint to get the user's current house
• Endpoint to create a new house, owned by the creator.
  • Usable by people who are not in a house
  • The house must have a unique associated code that can be used to join it
• Endpoint to join a house with a code, that will add the user to that house

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.

An easy way to waste time is to wonder why some API calls aren't working as we'd expect. Since we are using swagger (OpenAPI), it would be nice if we could leverage that, alongside typescript, to create type definitions for our API.

Describe the solution you'd like

Investigate tools that will allow the generation of TypeScript interfaces from swagger documents, such as this. These tools will likely want to use the swagger json located at http://localhost:4200/api-json (when the api is running).

If something like this looks promising, then implement an npm script (located in the frontend package.json) that will generate a file containing all type definitions for our API. If more complex logic is required, then the npm script can always simply run a single javascript file with the logic implemented in there.

Acceptance Criteria

If I run a script (for example, npm run generate), then a file inside the frontend directory (maybe in src/typings) will be generated/updated that has type definitions for our API.

Is your feature request related to a problem? Please describe.

Task splitting (i.e. chores) is essential for any flat sharing application.

Describe the solution you'd like

WIP - we will need to have a meeting to spec this task out.

Potential requirements:

• Able to add chores with frequencies
• Assigns those chores to people
  • Assignment could be manual, round robin, random etc

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
In order to start integrating the app together, we should add a dashboard for logged in users.

Describe the solution you'd like
A dashboard page (partially functioning) that allows users to navigate to other parts of the application.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Bill splitting is an essential part of a flat sharing application and is the backbone of this app. Users should be able to create and share bills with their flatmates.

Specification

• User can add bills to a flat.
  • The user who makes the bill is the owner.
  • Should have a description of what it is for and how to pay.
  • Upload pdf option.
  • Bills have due dates (will be sorted by due date).
  • Add users from the flat to bill.
  • Enter manually the number to be paid from each user.
    • Shortcuts to split bill evenly.
• Users can mark bills as paid. Will show on the bill which users have paid.
  • Optionally the user can upload proof (as image).
  • Can unmark as paid if accidentally marked as paid.
• Save a bill as a template.
  • Templates can be loaded quickly when creating new bill.

Back-End Specification

• Introduce new bills table with the following columns:
  • Name,
  • Description,
  • Owner,
  • Due,
  • Users,
    • id,
    • amount,
    • paid (boolean),
    • proof (blob storage id)
• Proof should be able to be accessed from blob storage.
  • https://firebase.google.com/products/storage.
• Add endpoints:
  • GET /house/bills
    • Retrieve all bills in the users flat.
    • Bills Ordered first ordered by not paid first then paid.
      • Then ordered by the due date (most urgent at top).
    • Response structure should be the same as db structure.
  • POST /house/bills
    • Create a new bill.
  • PUT /house/bills/{id}
    • Update a bill.
    • Ensure requestor is the owner.
    • Can only update name and description.
  • PUT /house/bills/{id}/payment
    • Mark a user as having paid or unpaid a bill.
    • Optionally, can include proof ID
  • DELETE /house/bills/{id}
    • Delete a bill.
    • Ensure requestor is the owner.
  • GET /house/users
    • Return all users in the house

Considering a bill paid

• If the user is the owner then the bill is considered paid if all users have paid. Otherwise it is unpaid.
• If the user is not the owner, then the bill is considered paid if that specific user has paid. Otherwise it is unpaid

Sample Bill Response

{
  "id": "ObjectID",
  "name": "string",
  "description": "string",
  "owner": "FirebaseID",
  "due": 23424223,
  "users": [
    {
      "id": "FirebaseID",
      "amount": 23.00,
      "paid": false,
      "proof": "BlobID" //Optional, should get from front-end
    }
  ]
}

Additional context

Add any other context or screenshots about the feature request here.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
Bill splitting is a core feature of the application.

Describe the solution you'd like

These are the specifications, ask for any clarifications

• Add a new PRIVATE page - /bills.
  • Add to private page router.
  • Dashboard: bill splitting card to navigate to bill splitting page.
  • Should list bills:
    • Bills ordered first by not paid, then paid after.
    • Then ordered by the due date (most urgent at top).
    • Suggestion: make design similar to the “upcoming” cards on the dashboard page, but ultimately up to implementers.
    • This card should show the bill name, description, cost.
  • People can click a bill to open a details page.
    • This page should be on /bills/{id} - to implement this and for getting path params, look at the react router.
    • There the user can upload proof (pdf or image).
    • This will be uploaded to here.
    • Generate a uuidv4 string (npm uuid), name the file that, send the generated link to the backend.
    • The details page should also name the bill, show description, cost etc.
    • There should be a button (i.e. a toggle) to indicate it is paid.
      • You do not need to upload a bill in order to select this toggle.
    • The OWNER of the task should be able to edit parameters, such as the description, name.
  • Go back to the dashboard button.
  • At the top of the page there should be an option to create a new bill
    • This can be modal:
      • Bill name.
      • Description.
      • Due date.
      • Total cost.
      • Option for splitting bill evenly (default on)
      • If unchecked, show a table of all the people in the house, the user can enter specific quantities for each user to pay.
  • Also ensure a go back to dashboard option at the top that navigates back to the dashboard.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
We could integrate l10n related features even without the requirement of having this web service in another language

Describe the solution you'd like
As we may constantly adjust our front-end design, change/addition of textual content (i.e. text paragraph, button text, etc) could be necessary. The use of hard-coded inline string within JSX could be difficult to make changes to these texts, and potentially cause bugs. Such hard-coded smell could easily be fixed by introducing a centralized configuration file that contains all textual content of the front-end service, which makes this file the only place that needs to be changed for textual adjustments. This could even be helpful for the textual content formatting purpose, and if we decide to expand the service to support another language.

Describe alternatives you've considered
react-intl https://formatjs.io/docs/react-intl/

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
As a developer, I would like to have a common code style in the React application to make the code consistent and more readable.

Describe the solution you'd like
A Wiki page outlining the code style of the react side of the app.

The proposed react conventions are written here:
https://github.com/701-T4/platform/wiki/React-Code-Conventions

Is your feature request related to a problem? Please describe.

Ideally, we would like to have a basic schedules page that could show some information such as move in and move out schedules.

Describe the solution you'd like

WIP - we will need to have a meeting to spec this task out.

Potential requirements:

• Ability to set your move-in and/or move out dates for the flat.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Specification

• Users can create tasks and assign them to any user.
  • Tasks can be edited by anyone.
  • Can be assigned randomly or fixed.
  • Can be recurring.
    • Done state is reset on a given frequency.
    • If randomly assigned, pick a new user.
• Users can mark tasks they are assigned to as done.
• Users can delete tasks.

Back-End

• Introduce new “tasks” table with the following structure:
  • name,
  • description,
  • last_completed (optional, time),
  • due_date,
  • interval (optional, in seconds),
  • assigned (user id),
  • pool (optional, user id array)
• User Pool - random user from pool will be assigned to task.
• Recurrence Rules:
  • Recurrence should be checked whenever a task is queried before it is returned.
  • If the current time is past due_date + interval:
    • Set to incomplete (delete last_completed column).
    • Set due date to (due_date + interval).
      • If this is in the past increase by interval until the future.
    • Reassign from user pool, if needed.
• Endpoints
  • GET /house/tasks
    • Return all active tasks in the house.
  • GET /user/tasks
    • Return all active tasks assigned to user.
  • POST /house/tasks
    • Create a new task.
  • PUT /house/task/{id}
    • Ensure requestor is the owner.
    • Modify task name, description or pool.
    • If assigned user is no longer in pool choose a new assigned user.
  • PUT /house/task/{id}/completed
    • Mark a user as having completed (or not) a task.
    • User must be assigned.
  • DELETE /house/task/{id}
    • Delete a task.
    • User must be owner.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
We currently only have 2,000 minutes of github actions. With our current average runtime of PR check this translates to 66 commits a day. This will be further reduced if we add in a deployment workflow.

Describe the solution you'd like
Restrict the PR check action to only running if the PR is open and not draft.

Describe alternatives you've considered
We could attempt optimisation to try drive down the execution time but I don't think we will be able to reduce down from a minute very much. Not an efficient use of time or energy.

Is your feature request related to a problem? Please describe.
External documentation, decisions and meeting minutes should be moved to GitHub wiki as per assignment requirements

Describe the solution you'd like
Pages should be created for each

Additional context

• Project Proposal
• Specifications
• GitHub Checklist
• Meeting Minutes
• Team Agreement
• Organise pages into sidebar

Is your feature request related to a problem? Please describe.
We need a boilerplate react app in order to begin large scale development.

Describe the solution you'd like
A create-react-app boilerplate, with a basic guide on how to contribute, a scaffolded directory layout, routing, a data fetching method, CSS framework (i.e. tailwind) for our own designs and layouts, a component library for rapid development (NextUI)

Other alternatives
NextJS - won't use as it is slightly more complex and hosting may be more complicated.

Is your feature request related to a problem? Please describe.
currently we do not have a way to get all of the users in a house

Describe the solution you'd like
update endpoint GET /house so it also return users which is an array of UserResponseDTO
update endpoint PUT /house so it assigns the user to another house

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
Loading screens help indicate to the user that the app is doing something, improving responsiveness (as opposed to just rendering nothing)

Describe the solution you'd like
Loading components

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.

Wifi password sharing (and other passwords such as router logins) commonly want to be shared by flatmates.

Describe the solution you'd like

• A page for this feature designed on Figma
• That design implemented in react
• Controller/View pattern used. Controller should be used for fetching the data, and adding new data.
  • This can be faked until the actual backend endpoint exists, such as just by hardcoding the data in the controller.

Specific AC

• Users can add notes (essentially key-value pairs)
• Users can select for the values to either secret or visible (secret can just mean the text becomes '●●●●●')
• Users can delete notes (modal for confirmation)
• There should be a card-like component essentially warning users that very secret information (i.e. important passwords) should not be stored on here.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Describe the bug
The typings on useAuth are incorrect.

To Reproduce

1. Do not sign in
2. Firebase currentUser is therefore null
3. useAuth() does not indicate that it is possibly null.

Expected behavior
Allow the user to be null.

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. bug, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
As a developer I would like an easy way to manage all the individual packages in this repo.

Describe the solution you'd like
A Lerna monorepo will improve the developer experience by simplifying project setup.

We could have two packages:

/backend
/app

Furthermore, the root level monorpeo should contain any pre-commit hooks, such as for linting.

Describe alternatives you've considered

• No monorepo system, could just have two packages.
• nx, but might be a lot of setup and boilerplate.

Is your feature request related to a problem? Please describe.
code should be heavily tested to ensure stability and correctness

Describe the solution you'd like
Investigate test runners that would be best for this project and implement it.
Please coordinate with @701-T4/front-end as they may use the same test runner.

Is your feature request related to a problem? Please describe.
Right now the login page is just blank with a sign in button. We should try to make it look nicer.

Describe the solution you'd like
Implement an actual login page.

Additional context
Potential design ideas:

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
We need to develop a base for our back-end infrastructure.

Describe the solution you'd like
A ping endpoint lets us get the initial development done so we can expand later. It will also be used by front-end to verify setup.
It should simply respond with the current time (JSON format).

Describe alternatives you've considered
I cannot think of any endpoints that would be constructive to the final product at this point in time.

Describe the bug
FindByCode query built from user-controlled sources allowing query injection attacks

To Reproduce
By entering a query injection string such as {$ne: '23424423'} it is possible to join any room or modify the database

Expected behavior
It should instead search for a room with the code "{$ne: \'23424423\'}" which will not exist and thus return 404.

Additional context
https://github.com/701-T4/platform/security/code-scanning/1?query=ref%3Arefs%2Fpull%2F61%2Fmerge
https://mongoosejs.com/docs/migrating_to_6.html#sanitizefilter-and-trusted
https://mongoosejs.com/docs/api.html#mongoose_Mongoose-sanitizeFilter
https://masteringjs.io/tutorials/mongoose/query-string

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. bug, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
Its important to give contributors context and information about how to contribute to the project. This thread will discuss root-level files that we would want in our project.

Describe the solution you'd like
I propose the following configs and documents:

License

I'm defaulting to MIT but if anyone has a preference (i.e. gpl family) then please discuss.

Contributing.md

A summary guide on how the project should be contributed to, such as git conventions, code review conventions etc.

Readme.md

A file introducing the project, and usage for end users.

.gitignore and .gitattributes

Repo related files to be ignored and gitattributes to enforce things like line endings and treating files as binary. Going to suggest that if you haven't already, I suggest placing your IDE and OS files in a global gitignore since these aren't really relevant to the repo.

CODE_OF_CONDUCT.md

Outlines the rules for contributing. I suggest we just use one like this

CODEOWNERS

Gives us the ability to assign ownership over certain parts of the code. This means contributors know who to ask for reviews when modifying files or directories (and can even be set as a branch protection requirement). Keen to hear others thoughts on this.

.editorconfig

Apply some global styling rules (although may be unneeded if we are going with the monorepo structure).

Anything else?

If anything here seems unneeded, adjusting, or anything is missing, please discuss below.

Implemented in #5

Is your feature request related to a problem? Please describe.

We want new users to be able to see what our app is about before creating an account. There should be a button that can redirect users to the create account page.

Describe the solution you'd like

• A basic design for the landing page
• That design to be implemented into the frontend
• Buttons (i.e. in a top navbar) that will redirect the user to our signin page.

Additional Context

Example landing pages:
https://discord.com/
https://www.sushi.com/

Obviously they are not needed to be near as professional as those, that would be more stretch goals. For now, something extremely basic with a title and a navbar up the top with a signup/login button would be acceptable for this to be complete.

Is your feature request related to a problem? Please describe.
We need to check the bearer tokens that are provided by front-end to verify the user is valid.

Describe the solution you'd like
Uses the firebase auth token to check that user is valid and exists in our database.
If it doesn't exist in our database create a new user in our database using the provided ID

1. See if request has bearer token in header and is valid JWT
2. If it is valid:
   1. Check if the user exists in mongodb database
   2. If they exist: let endpoint return as normal
   3. Else create user and then let endpoint return as normal. (create user part moved to issue #41)
3. else return 401 if there is no token or 403 if the token is invalid

As part of this issue please create a method in the user service that returns the currently logged in User

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project

Is your feature request related to a problem? Please describe.
We need to check all the licenses of our dependencies to ensure they are compatible with our project

Describe the solution you'd like
We need to go through each dependency and check if we are able to use it, and if so are there any conditions to use?
We may have to add an attribution section to our app. Potentially could also attribute in the wiki but unsure

Also should add a check in the PR checklist to add any attribution required

Checklist:

• I have double checked that the issue does not currently exist.
• I have added the appropriate labels (e.g. feature, front-end, back-end).
• I have added the Platform Project project