mstojcevich / cs4711-wiki Goto Github PK

Images should be uploaded and saved to the server somehow.

Serving the images is not in the scope of this task.

Determining and storing image metadata like dimensions is tough on its own, so that is not in the scope of this task.

DoD: An API endpoint exists that uploads an image to the server, tracking the user who uploaded it, the upload datetime, and an optional comment.

Django already provides testing for free, but we need to make sure that running these tests works with pytest out of the gate (it should).

Spike result: Decided on pytest-cov

DoD: Running some command should run all of the backend tests and give a result

Depends on #46

Images created using our image extensions should be viewable in the Quill editor.

In addition, clicking on one of these images will open an image view modal.

This is from the assignment description page

Sub-issues:

• #27

It would be nice to be able to dev the backend and frontend together without having to have two separate workflows. In addition, we need a way to deploy the backend and frontend together in production, and this may ease the process.

We might be able to use webpack or something similar.

Home page should be scaffolded. (Will show recent articles, login/register buttons, search bar for articles).

File structure should be the following:

src/components/HomePage/HomePage.jsx, src/components/HomePage/HomePage.test.jsx

This can be as simple as returning a header that says 'Home Page'.

DoD:

• Component is routed to on /

• Tests exist for rendering the component (see src/App.test.js)

• Commenting exists at the top of the component describing its purpose

We should decide on what we want to do regarding development.

There are several questions:

• Will we require code review or just passing builds or neither (pls no)?
• How big should PRs be before trying to merge into master?
• Should we enforce no drops in coverage (must test all new code)?
• How do we decide on which libraries to use for certain things?
• How strict will we be on code style?

We need a modal for image uploads. It does not need to perform the actual upload, but should be able to select an image.

DoD: A modal is designed and tested which allows a user to upload an image, specifying a comment to go along with it.

Depends on #42

This will likely require some sort of image processing library, and may be tough to do securely.

DoD: Newly uploaded images should have their image dimensions saved in the database

We can reuse the "compose" page that's currently being used for only new articles. Ideally we would avoid code duplication and have it literally be the same exact React component.

We need to pre-fill the editor and the title field, along with keeping track of which article is being updated.

DoD: A page exists to edit a specific article. When the submit button is clicked, visiting the article view page shows the new content.

We should have a list of banned IPs in the backend.

This task does not include enforcing the bans in any way.

DoD: An admin panel page exists to add banned IPs

From the project description.

Sub-tasks:

• #31

DoD: A page exists that lists all the articles and gives a link to the view page for each one.

The articles API should keep track of different revisions of articles.

When getting an article's details, the content for the most recent revision should be shown, and links to previous revisions should be available.

When editing an article, a new revision should be made and tracked.

This feature should be transparent to the current frontend. Editing an article and viewing an article should require the exact same API calls as before.

DoD: When an article is edited, the previous version and current version should both exist somewhere in the database.

In order to have successful continuous deployment, we need some way to make sure the deployment is "good" before switching to it. The easiest way to do this will be to have a sort of "self-test" in the way of a health page.

The data returned by the page should be easily parse-able by a script, and should contain the following info:
Database status: Can you connect to the database?
Memory utilization of the server
Disk utilization of the server

This health page should be easy to extend if more information is needed.

DoD: Visiting the /health url gives a computer parse-able status containing the details mentioned above.

We need to create an extension for Quill that adds image uploading to the toolbar. This should use our image modal that we create in #45.

We can't use Quill's built-in image support, since that does not include all of the metadata that we require images to have.

DoD: A button exists on the editor toolbar that allows for uploading an image via our image modal.

The API should capture all URLs not specified as API routes, and return index.html.

The frontend should be able to swap out components based on the url without triggering a page refresh.

This can be done with React router but it might be nice to have something simpler instead.

DoD: Routing system in place, / serves some default page, all other routes serve a 404 page

Initialize react project.

DoD:

• Developer can run a dev server that proxies to the Django server
• Developer can run a build that can be served by the Django server

User settings page should be scaffolded. (Will show inputs for changing username and password).

File structure should be the following:

src/components/UserSettings/UserSettings.jsx, src/components/UserSettings/UserSettings.test.js

This can be as simple as returning a header with the text 'UserSettings'.

DoD:

• Component is routed to on /{username}/settings

• Tests exist for rendering the component (see src/App.test.js)

• Commenting exists at the top of the component describing its purpose

This will require:

• A docker image for running the code
• A .gitlab-ci.yml file specifying the docker image and what to do for the different pipeline stages
• A gitlab mirror of this repo

Related documentation:
https://docs.gitlab.com/ee/ci/yaml/

DoD: Once someone makes a change, a pipeline is launched on Gitlab where a developer can see the status of tests.

We need a way to list revisions of an article and get the contents of a specific revision

DoD: Existing article endpoint is extended to have a list of revisions. API endpoint exists to view article revision.

We need to persist user sessions. Probably want to save the token given by authentication in a cookie and have some way to re-validate the token in the backend. More specifically, we should treat the token as the only "source of truth", and we shouldn't store stuff like username and user id locally; we need a backend handler which takes a token and gives the additional info like username and user ID.

DoD: A user who refreshes the app remains logged in.

Depends on #40

We probably need to extend django-rest-framework's permission support to do this in a clean way.

IP banned users should retain read-only access, but should be unable to modify articles or create new articles.

DoD: A user connecting from an IP that's in the banlist should not be able to perform actions that modify the DB in any way.

DoD: The article list API should have some way to filter articles

Currently we just assume that if a user has signed in at any point, they are still signed in. What happens if the backend is inconsistent with the frontend?

We need a way to check if the token saved in the backend is still valid each time that the page is loaded.

DoD: Invalidating a token in the backend should log a user out of the frontend

There should be a navbar component that persists through routing.

It will contain:

• Search bar

• App title

• Login/Logout link

• Maybe a register button

DoD:

• Navbar renders on every page

• Rendering is tested

This modal should show an image, its upload date, the user who uploaded it, its size, and its dimensions. This data will come in from the backend.

DoD: Image modal component exists that shows the specified info.

We should have an authenticator component for restricting navigation to certain pages if a user is not logged in.

This component could just wrap a page and return the wrapped page if the user is logged in otherwise it would return the login page.

DoD:

• User settings page and edit page are restricted

• All API requests are done through one class, components have access via props

Users should be able to register.

The backend API for this already exists, we just need a frontend page for it.

DoD: A page exists where a user can enter a username and password and have an account created for them.

When a user logs out in the frontend, their token is technically still valid.
This poses a problem if the token is ever compromised: signing out should invalidate the token.

DoD: When the user signs out in the frontend, the token associated with the session should be gone from the database.

Once the backend has coreapi enabled, we can implement it in the frontend via the coreapi.js library.

This will allow us to make all of our API requests, authenticated, without having to keep track of authentication ourselves.

DoD: We can make authenticated requests to the backend API

Depends on: #17

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

Currently we just wait a fixed amount of time, assuming that attempting authentication will be done by the time the timeout finished. This is bad.

We should have the user be a promise, which resolves once the user is either logged in or guaranteed as logged out. This promise might also include the API schema being loaded with respect to the current user's permissions.

Articles are lots of text with a title, post date, latest update date, and an author. We can figure out more details as we move forward.

The article list API should not give the entire contents of the article, but instead should give only the title and author (and maybe a bit more info). The API for getting a specific article should give the full info.

• Create models for article
• Attach models to an API, writing necessary validators along the way
• Document the API on the wiki

DoD: APIs exist to create articles, view an article, update an article, and delete articles

This is from the project description.

Additional info (also from project description): Clicking on an image should bring the user to a page with metrics about that image, including the date/time it was uploaded, by which user, its dimensions, size, and any comments included with the image upload.

Please create subtasks instead of changing/pointing/claiming this one.

Sub-tasks (general):

• #42
• #43
• #44
• #45
• #48

Sub-tasks (quill support):

• #46
• #47

We should have a wiki page describing how to run linters and code formatting tools.

DoD: Wiki page exists containing commands to run to lint locally.

We should check JS code for lint failures/warnings before we write so much code that it becomes impractical.

DoD: Gitlab CI task exists that fails if there's a JS linter error

Setup the Django project.

• Django project created
• Pipenv exists for dependency management

DoD: A developer can run some start command then visit a url to reach the web server.

Dependent on #38 and #27

When a user tries to edit a locked article, they should be informed by the UI in some way that the article is locked, so that they don't continue editing and get disappointed when they can't save the edits.

DoD: Locked articles look different in the UI, indicating that a user cannot modify them

Edit/Create article page should be scaffolded. (Will show markdown editor or something similar).

File structure should be the following:

src/components/ArticleEdit/ArticleEdit.jsx, src/components/ArticleEdit/ArticleEdit.test.js

This can be as simple as returning a header with the text 'ArticleEdit'.

DoD:

• Component is routed to on /article/{1234}/edit or /article/new

• Tests exist for rendering the component (see src/App.test.js)

• Commenting exists at the top of the component describing its purpose

Admins should be able to "lock" articles through the admin panel.

When an article is "locked", a regular user cannot change it.

DoD: A user editing a locked article should get a 403 forbidden and the article should not be updated.

Article page should be scaffolded. (Will show article text, edit button, change history).

File structure should be the following:

src/components/Article/Article.jsx, src/components/Article/Article.test.js

This can be as simple as returning a header with the text 'Article'.

DoD:

• Component is routed to on /Article/{1234}

• Tests exist for rendering the component (see src/App.test.js)

• Commenting exists at the top of the component describing its purpose

The frontend needs some way to authenticate w/ the backend.

It seems like django-rest-framework makes this easy, but I'm not sure.

Depends on #42

Somehow serve the uploaded images to users

DoD: A URL pattern exists which can view images based on their IDs

A user profile page should give the following info about a specific user. We should be able to easily add more later.

• Username
• List of articles authored

This depends on #3

The frontend code should also be tested as part of the Gitlab CI pipeline

DoD: Failing frontend tests fail the pipeline

Running the CI locally is pretty slow and requires docker and gitlab-runner. We should document how to run both the frontend and backend tests locally.

DoD: Wiki page exists explaining how to run both frontend and backend tests.

This is from the project description. We already get admin accounts and the admin login page for free from Django.

Please create subtasks instead of changing/pointing/claiming this one.

Sub-tasks (page locking):

• #38
• #39

Sub-tasks (IP banning):

• #40
• #41

Add coreapi, including an endpoint to generate a schema.