ccortezia / featuring Goto Github PK

An undecorated yet functional frontend

• should not yet depend on a backend API
• should not yet care about login

Unit tests should be at least runnable. They are facing some sort of tooling issue at the moment.

Should prevent access to data in some situations.

Currently:

• update of own user profile information
• update of other users profile information
• creating user accounts
• listing other users profiles
• deleting other users profiles

Signup records that are never activated should be dropped after a while.

Evil clients should not bomb the app.

There may be some inconsistencies lurking there. It should be reviewed.

Should basically be slug compliants

An user should be able to update its full name and its login password.

The presentation of a given feature priority should take into account the value of this same property on the other documents of the same family (grouped by clientId).

The presentation of priorities will be made through the ordering of the elements on the list (top down from highest priority to lowest). The manipulation of the priority field might be made through the list directly. At first, an arrow widget will be inserted into each element of the list so an element can have its priority raised (and thus take place of the element upwards, since there can be no repetition of priorities).

Currently looks weird, title font is too big.

Strong password rules should be set on the backend, and propagated into the frontend.

Currently not enabled.

People may forget their passwords, but it is not a problem if they can get a new one through a secure channel.

Should allow outsiders to sign-up for the service unsupervised.

• an outsider user approaches the login page
• the user clicks sign-up button
• the user fills the username + email fields
• the user clicks confirm
• the system asks the user to check his email
• the user open the received email, and clicks the activation link
• the user is redirected to an account activation page
• the user fills the "new password" field and click activate
• the user is redirected to the login page (she may use her brand new credentials)

After editing the description of a feature request record, its presentation on the details page doesn't seem to respect line-breaks.

A possible fix would be to accept markdown formatting on the edit field.

Should require clients to send authentication information with every request.

Currently a feature is deleted immediately after clicking the DELETE button. There should be some sort of user confirmation prompt before actually deleting it.

Currently every jwt created has the same expiration period defined as per an application deployment setting. It should be possible for an user to determine at login time if he/she wants to be remembered across application reboots, or forgotten upon browser tab close.

Steps to reproduce:

1. delete the features from a client group until there is only one left
2. create a new feature on a different client from the step 1
3. edit this newly created feature changing its clientId to that of the step 1
4. try to chance priorities on any feature of client from step 1, and assert the bug

Currently the field deadline is optional and is being left blank.
A proper datetime component must be used to fill this field.

The responsive auto-hidden menu may be opened upon login. It should be always closed upon login.

The deployment project will be able to package and deploy the first backend implementation

Should store credentials locally and send them with every request to the API

By entering /deatures/new on the browser navigation, no record is loaded.
By entering the creation screen through internal links, all is good.
Buggy behavior.

Real datasources for the frontend

• should hold the data schema project (for now)
• should provide the feature records through the api

Should be as simple as changing the dummy implementation of the api-proxy for a real one that reaches the network

Current layout is not really responsible. Its rendering should provide an useful app despite the screen being narrow.

There may be some inconsistencies lurking there. It should be reviewed.

Regards automation of environment setup and simple deployment automation:

• should allow local reproduction
• should aim for the frontend only for now
• should allow deployment on some public machine

Add to priority field:

• should not repeat on records belonging to the same client
• should automatically be sorted when updated through the api

Should prevent multiple requests from inpatient users.

Forms to review:

• feature edit
• feature create
• feature detail (delete)
• user edit
• login
• register
• activation