ckesoglou / 31242-aip Goto Github PK

This could include implementing timeouts and rate limits, or even implementing techniques like password peppering.

This isn't a part of the required specification, so there's no rush to complete this item.

This depends on the front-end framework we end up choosing in #1.

Arguably the most common unit testing frameworks are Jasmine, Mocha & Jest. Feel free to add your own poll options using gh-polls if you have any other suggestions.

Handle frontend (fetch) calls to backend properly

While addressing feedback in #10, there was a number of changes made to what would become the final database schema.sql file. However, not all of these changes are currently present in erd.png (such as the removal of the is_admin attribute on users).

The ERD needs to be updated to ensure consistent documentation.

TypeScript provides static type checking (allowing errors to be caught early at compile time), but comes with a lot of syntax overhead. Javascript or TypeScript are both valid choices but must be used throughout according to spec. This probably includes the code for whatever front-end framework we decide in #1 .

AC:

• form including username, display name, password
• loading animation
• disabled button after click
• validation?
• redirect to homepage

Should we use an SQL database, or document-based non-SQL database? After this decision, another will be made on the exact database server to use.

• Cyclic dependency detection algorithm?

• Adding rewards
• Detailed info button

The issue is to create the backend API for user profiles

As various members have worked on designing, building and solving different parts of this project for the first time, we all possess knowledge unique to our sections that may not necessarily be known to the entire team (such as how to approach or complete issues, or how to structure it to maintain consistency).

To help each other as we continue to now work on other sections of projects, we should all contribute to a write up in the README of how to go about contributing to each aspect of the software.

These can include:

• How to do API designs (including recommended tools) and how to generate the documentation
• How to utilise environment variables and connect the backend to the database
• Structure of code within the backend and what test libraries/methods to utilise
• Structure of code within the frontend and what test libraries/methods to utilise
• Anything else you believe would be useful knowledge to possess, or needs to be consistent throughout the project

Please note that filtering by keyword AND/OR by reward item is required by the spec.

You may also want to consider allowing user defined ordering (assuming the api has support for it)

Currently blocked by #35

This endpoint does not require authentication. EDIT: the linked pull request also implemented the rest of the requests backend endpoint (rather than just browse), including some that required authentication.

Currently blocked by #35

According to the spec, we must choose either React or Angular

A deployment job was cancelled at the build stage after warnings were encountered (since these are automatically treated as errors by the deployment script). This behaviour may be good to keep, but should have been caught at the continuous integration testing stage when the pull request was created.

Looks like the ci script calls npm build when it should be npm run build - it is currently not correctly building the project.

All open (incomplete) requests should be viewable by both authenticated and unauthenticated (anonymous) users.

This issue covers the API design for this feature. It should NOT include the endpoints needed to create nor complete the request, only view.

Consider the following when designing this API:

• How to order the items in the response by default
• Whether or not to allow custom ordering by the user in the request and how to do it
• How to implement custom filtering by the user in the request. Filtering by keyword(s) or by reward items is required at a minimum by the spec
• How to handle situations where 1000+ open requests can be returned (API pagination? From/to index?)

Based on the data this application will collect and the ways it will be processed, create a privacy policy txt document that will be linked to and displayed by the application.

A bad merge in #43 broke the automatic deployment script.

This can be resolved by restoring the original version in the master branch, overwriting the local one introduced in @seant1 's branch.

Prettier was decided by the group to be a great tool to ensure consistent code formatting across the project. For this issue, add it as a dev dependency, configure the required settings and ignore files (eg: ignore directories like build, dist, node_modules, etc), and run it on all existing files.

Support for e.g. dark/light mode. Fix unused themes warning.

AC:

• unit tests
• JWT
• JOI validation

#11 did not include the required change to azure.yml deployment script to handle installing & building the front end, followed by the back end.

AC:

• unit tests
• authenticate helper function

This issue is to create the user profile after the home page linked to the user DAO

AC:

• unit tests
• linking to backend

Display returned data elegantly

AC:

• pagination
• return only needed data

It appears the same merge (#43) that caused problems in the CD script (#46) also include at least one other file with unresolved conflicts, found in docs/API Specification.md.

The origin of this conflict appears to stem from a3c1a32, which at the time also included conflicts in:

• .github/workflows/continuous-deployment.yml
• docs/API Specification.md
• react/src/api/endpoints.tsx
• react/src/assets/css/login.css
• react/src/components/App.test.tsx
• react/src/components/App.tsx
• react/src/components/theme.test.tsx
• react/src/index.tsx
• react/src/pages/README.md
• react/src/pages/login.test.tsx
• react/src/pages/login.tsx

I imagine most of these have been resolved since then, however we should definitely go through and double check there aren't anymore outstanding conflicts beyond the API Specification file.

See #13 for context

We need to decide on a cloud provider to host the application and database. Through various channels, we can essentially get free credit from any of the major providers. Consider the ease of use in deploying to these services (perhaps even automated deployment with any master branch changes).

This issue is to create the api design. This will be a joint effort with the back-end developer.

AC:

• truncate appropriate responses
• multipart form data for image upload
• examples

Identify components/views required and design user interface based on features in spec

The use of refresh tokens to allow for a user to renew their authorisation and stay logged in requires the storage of these refresh tokens by the server, so that they may be revoked when necessary.

The spec calls for a limited list of favours to be selectable (ie: favours are chosen from a predetermined list rather than free text by the user).

There's a minimum limit of 5 favours as per spec, but no upper limit. Favours must be "low value items with an element of 'fun'". Monetary values are not allowed.

Leave each suggestion as it's own comment below - that way we can use thumbs up reactions on the ones we like.

These will eventually be stored in the database - NOT hardcoded in the software. This is to allow for potential future enhancements such as allowing an administrator to modify this list. Let's try and finalise this initial list by end of week.

Also consider the phrasing of these items. It is assumed they will be displayed as something like this:

• I owe John X
• John owes you X
• Complete this request to get X

AC:

• empty required fields should prevent submission
• display error messages based on API response

Notes:

• Server-side validation (validating/verifying inputs) is scoped into separate API implementation issues

Looking at the recent GitHub Action logs, it appears everything is being run in the root directly and is simply building and testing the express back end twice.