mstojcevich / cs4711-wiki Goto Github PK
View Code? Open in Web Editor NEWA wiki site
License: Mozilla Public License 2.0
A wiki site
License: Mozilla Public License 2.0
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.
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:
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
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:
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:
.gitlab-ci.yml
file specifying the docker image and what to do for the different pipeline stagesRelated 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.
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):
Sub-tasks (quill support):
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.
DoD: A developer can run some start command then visit a url to reach the web server.
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.
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.
Add coreapi, including an endpoint to generate a schema.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.