Test Issue: Save and read red alert status

[iturgeon]

This a test issue to help get familiar with the workings of the project.

Need to add a button to the left-hand nav in the viewer that, when pressed, turns the background of the Navigation to red. Pressing it again would return the nav back to normal. Also need to log when the nav is set to the red alert state and returned back to the normal state.

If you haven't yet, fork the main repo. You'll be working off of your own branch on your own fork. Next, create a new branch to work on - git checkout -b issue/89-red-alert-status (off of your fork).

You'll also want to check out the documentation at https://github.com/ucfopen/Obojobo-Docs and also the project code style guide at https://github.com/ucfopen/Obojobo/wiki/Developer-Code-Style-Guide

Here would be the steps to implement this:

In the obojobo-document-engine package:

• Add a new event handler to NavStore to listen to nav:redAlert. The payload of the event should include a boolean to indicate if red alert is on or off. This event handler should call APIUtil.postEvent to send a nav:redAlert event to the server.
• Modify the state of NavStore to include a new redAlert property holding a boolean if red alert is enabled or not.
• Add a new method to NavUtil called setRedAlert to fire the nav:redAlert event. The method should take a boolean to indicate if red alert should be enabled or not.
• Add a button to the nav component. Clicking this should call the NavUtil.setRedAlert method.
• Add a query method to NavUtil - isRedAlertEnabled - that will return a boolean to indicate if red alert is enabled or not
• Add two new CSS classes in the nav component - is-red-alert and is-not-red-alert. The nav component should use the NavUtil.isRedAlertEnabled method to figure out which class to apply to the element.
• Add a is-red-alert style to the nav component scss file which turns the background of the nav red.

In addition, you'll need to ensure 100% test coverage. This is not an exhaustive list but here are a few example things you'll want to test:

• [ ] - In viewer-app.js test that clicking the button toggles between setting the is-red-alert and is-not-red-alert classes on the appropriate element.
• [ ] - Add a NavUtil test ensuring that NavUtil.setRedAlert calls the Dispatcher.trigger method with the correct parameters and that NavUtil.isRedAlertEnabled returns expected values with given inputs.

In the obojobo-express package:

Need to store the red alert status in a specialized table in the database to persist this value. Also want to write the value of this to the page when viewing a draft and have the Nav read this value. The end goal would be able to enable red alert, then refresh the page and have red alert still be enabled.

The steps to implement this:

• Need to create a new migration which will add the database table. The package.json defines a few scripts to help with this - You can cd into the obojobo-express package and run yarn db:createmigration to create a new migration.
• The migration needs to create a table (called red_alert_status) with columns for a primary id, the user id, the draft id, the creation time and a boolean indicating if red alert is enabled or not (You can look at the existing migrations in the /migrations folder to get a feel for how these are written. You can also look up documentation - we are using https://github.com/db-migrate/node-db-migrate). Indices should also be created for user_id, draft_id and a unique index for both user_id and draft_id. As a reference, the migration create-attempts-question-responses creates a unique index. The unique index is needed because the pairing of the user_id and draft_id is what will be needed to uniquely identify a users interaction with a draft and if they've turned red alert on or not.
• When the nav:redAlert event is sent to the server the server will broadcast it as client:nav:redAlert (look in /routes/api/events.js to see this). The server will need to listen for this event and respond by inserting a new row into your red_alert_status table (or updating an existing row if that row already exists) - search the codebase for "ON CONFLICT" to see an example of how this is done. You can listen for events on the server by using the oboEvents library, search for "oboEvents.on" to see an example. This event listener needs to be somewhere on the server - for the sake of the exercise you can add it to the viewer-events.js file
• When the visit/start route is being ran (as in the user is viewing a draft and a visit is being started) the value of red alert status should be included in the response so the client can use it (add a redAlertStatus property in the response object). To do this you'll need to query your new database table to get the value of the red alert status in the visits/start route. Note that their might not be a row for a given draft and user id (if it was never set) so your query will need to account for that. (Really really minor note for the sake of completeness: If we were adding this feature "for real" the value of red alert status probably wouldn't be kept in it's own table. That's overkill. Instead it would live in the view_state table which is reserved for preserving the state of a draft and navigation (perfect for this case) but we're ignoring that for the sake of training!).
• Finally, the client application should read this redAlertStatus value and set its state accordingly. Back in the obojobo-document-engine package in viewer-app.js search for "NavStore.init" to see how values from the visit/start response are used to initialize the state of the navigation. The value of redAlertStatus should be passed into the init method for NavStore and NavStore should set the state of red alert to this value.
• Again, you'll need 100% test coverage.

I've left out some details on how to achieve some of these tasks - the existing code can be used as a reference, and if you get stuck feel free to ask questions to get clarification or some pointers. There is also a walkthrough you can use if you get stuck - https://github.com/ucfopen/Obojobo/wiki/UCF:-Walkthrough-of-the-Training-Issue

[iturgeon]

Comment by zachberry Thursday Mar 29, 2018 at 17:38 GMT

---

Completed so closing, will re-open for a new future dev.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep our backlog under control, but we thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep our backlog under control, but we thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep our backlog under control, but we thank you for your contributions.