halprin / retrospective Goto Github PK

Look into logging for Python. Create follow on story to implement logging based on what was found in this story.

Turn off the DEBUG setting.

Deploying frontend
./deploy.sh: line 25: ng: command not found
The user-provided path ./dist/ does not exist.

Make it such that ng is accessible and can execute.

Run manage.py check --deploy on the Django application. It will generate a list of issues for deployment. Create new issues for anything that needs to be fixed.

Instead of using the Elastic Beanstalk supplied DNS name, use a real one and point it to the production environment.

The number of votes you had remaining is still visible when viewing the results. Remove it. There is no need for it to be there.

DynamoDB can automatically delete items in the database based on a date/time. This is called TTL. Implement this such that retrospectives are deleted a month after they are created.

Improvements will be made to the Join frontend component as part of #40. Migrate the improvements that apply to the Start component.

Currently the frontend is cordoned off in the frontend directory, but the backend is split across multiple directory and files that are in the top level directory. This is messy. Cordon off the backend under a single, monolithic directory.

The frontend doesn't look good in certain mobile environments. The smaller the screen, the weirder it looks.

Today, sections available for a new issue is the unique set of sections across all the issues. AKA, you can make any section you want. Would it be better to be able to specify the set of sections before an issue is created? That would pull in what a valid section is into the backend from a frontend.

Test api.views.RetroIssueView's post method.

Test api.views.RetroUserView.

Test api.models.RetroStep.

Currently, any change in Terraform get applied to dev and prod. Any changes should only apply to a specific environment.

Add the ability to group issues after they have been created.

SECRET_KEY inside settings.py must be secret. Either hide it or see if I even need it.

During the results phase of the retrospective, sort the issues from highest vote getter to lowest vote getter. Decide if this sorting should be in the backend or frontend.

Pushes master should deploy to production, not dev.

Add manage.py check --deploy --fail-level ERROR to the CI build.

Reformat the Terraform files to the standard.

The checkbox for every issue, during the voting phase, is at the bottom of each issue's horizontal area. It should be centered.

Using the dev and prod environment always seems to produce a 401 Unauthorized User is not valid for getting the retrospective and adding an issue. There could be other endpoints affected by this.

The Join frontend component doesn't work or is incorrect. Fix it such that...

• A user must be able to join a retrospective.
• A user must be directed to the View component upon joining the retrospective.
• A user must be able to use a /join/<uuid> URL to pre-populate the ID field.

Nearly all the view methods have at least one of the following checks...

• The retrospective exists.
• That the user is an administrator.
• That the user is valid.
• That the retrospective is on a specific step.

Create a generic construct for all of this.

Look at https://docs.djangoproject.com/en/2.0/howto/deployment/checklist/ and create more stories where the application needs fixing.

Look at the ALLOWED_HOSTS and CORS_ORIGIN_ALLOW_ALL (and other possible CORS variables) and determine what they should be for dev and prod. Create stories to implement these changes.

Chrome doesn't like the sub-protocol!

Be able to remove a user from the retrospective. Must be the person him or herself or an admin. When a user is deleted the admin is given ownership of the deleted user's issues. If the admin is deleted, another random user is made the admin (and given the former admin's issues).

• Features
  • Ability to break ties between issues once in results phase.
  • Make votes weighted. First vote is most important and the last vote is the least important.
  • No need for ready button once in results phase.
  • Timer to help timebox issue discussion while on results phase.
  • Highlight current issue being discussed in results phase. Be able to advance to next issue which would grey out previous issue and highlight new current issue being discussed.
  • Added issues should appear at the top of the list and push the previously added issues down.
  • Ability to add notes to issues during the Results phase. Then be able to export a report of the retrospective.
• Design
  • Move the name of the retrospective farther down from the navbar or shrink up the navbar.
  • Move the join link under the Administrator/Users dropdown button.
  • Thicken color borders around the two sections of issues.
  • Change Administration/Users and the pagination to using the primary color.

Create the beginnings of a GUI for the application.

This application needs a method to deploy to production. It should be able to understand environments (like the development environment versus the production environment).

Test api.views.RetroView.

Delete an existing issue that was created. Must be the user him or herself that created the issue. The admin cannot delete other people's issues. Issues can only be deleted during the ADDING_ISSUES step.

The SQLite database gets created whenever the application runs. Stop that from happening since we don't use it.

Sometimes deployments randomly fail with a timeout. Figure out why and stop it. Is it possible that it just takes a long time sometimes?

Add a button to copy the frontend join link to the clipboard.

When a merge occurs to master, a deployment should ensue.

The number of votes remaining during the voting phase is a frontend construct. This should be brought into the backend and enforced there. Start with three votes per person. Return an HTTP 4xx error when someone tries to use two many of their votes.

Currently the retrospective updates its view every 10 seconds unless an action is performed. Change the architecture to use interrupts instead.

Poll but delay a response until something changes?
WebSockets?

Terraform is at version 0.11.5. Update to using that.

Use HTTPS for all communication for the frontend and backend.

The application doesn't support the browser refresh, forward, and backward buttons. Add support for this mostly on the viewing of the retrospective page.

For example, forward and backward could move the retro phase in that direction if you're an admin. If you aren't an admin... investigate this.

If a user refreshed the view, put the user back where they left off as if nothing happened.

Create a custom favicon icon for the frontend.

There's no easy way to tell if you are the administrator, know your name, and tell if you are ready. Add this ability to the ReST API.

The actual viewing of a retrospective as it occurs is, for the most part, missing. Implement it.

There is a state for a retro that allows grouping of issues. Remove it and clean-up the codebase.

Currently, there is no way to unvote for an issue during the voting phase. You vote for an issue and there's no going back. Add the ability to rescind a vote during the voting phase. Any other phase will result in a 4xx HTTP status.

Terraform can be blocked from deleting a resource by putting a lifecycle policy on the resource. Identify the resources that should not, under any circumstances, be deleted, and apply the policy to them.

Add the ability to vote for an existing issue.