Description
When a user with the capability to view the accountability tab, they should be able to account for members who need to be accounted for.

Solution
Backend and frontend functionality is created to successfully account for individuals.

When attempting to create a new account, the message "Email not available." is shown, even if the provided email is available to be used.

The correct functionality should be that the "Email not available." message is only shown when the email address is already in use for an existing user. Otherwise, the email address is considered valid and an account should be created.

The correct functionality was originally present before merging #34, so I'm hoping just some slight modifications are required.

Here is a screenshot of the current functionality after "Create Account" is pressed.

Some pages that should be protected by being logged in are currently accessible without being logged in.

For example, by navigating to novaemergency.live/novaweb/accountability.jsp, you are presented with all of the options for accountability without being logged in.

This is unintended behavior since sensitive pages that involve modifying items in the database should require a user to be logged in first.

To fix this, a check should be done before loading a page to see if a user is authenticated or not. If they are not authenticated, they should be redirected to the home page.

Description
In the NOVA project documentation it states that there should be a way for first responders to search for students and faculty and display their status as well as their name and emergency contacts.

Solution
Implement search mechanism on the first responder page.

Description
In the NOVA project specification, it states there should be a way for first responders to send status updates about the situation.

Solution
The backend functionality should be added that allows first responders to send status updates. Students, Faculty, and Administrators' views should correspondingly show the latest status updates.

Problem: Currently, any user visiting the application can request a new user account with any group privilege. This implementation was intentional, as it was designed to be used for testing. With this in mind, this feature has been pushed to develop and should be migrated to administrator only functionality as soon as possible.

Solution: Remove the register button from the login modal, and only allow the register modal to show while an administrator is logged in. This will prevent any user from registering with any group since they don't have the privilege to.

Current view of login modal with register link:

Current view of register modal:

Issue: I noticed that the cards for the student view have a dark background and could be hard to see for some users.

Solution: The titles of the cards should keep a dark background with light text, for visibility and to stick with the overall theme, but the body of the cards should have a light background with dark text. This will be similar to what theme is present currently for the card divs on the account page.

Here is an example of one of the cards that would need to be changed.

Each card on the index page, similar to above, would be changed to the following:

<div class="card mb-3">
   <div class="card-header bg-dark text-light"><h5>Law Enforcement/EMS Updates</h5></div>

By making this change, the appearance would go from this:

To this:

When logging in with a bad username/password combination, an error page shows with an IndexOutOfBoundsException. This is not intended functionality.

When attempting to login with a bad username/password combination, the user should be redirected back to the login modal and shown a message that states the username/password is incorrect.

The correct functionality was originally present before #34 was merged, so I'm hoping just some slight modifications are required.

The screenshot below shows the exception:

Problem: The hibernate.cfg.xml.example file contains the mapping for the classes that have hibernate annotations. Because this file needs to be copied during the import of the project and renamed to hibernate.cfg.xml.private in order for Git not to track the file, any new classes made that are referenced by the hibernate file will not automatically be updated in the .private file. This creates an extra burden on anyone working on the project and makes it harder to collaborate when pulling changes.

Solution: There should be a way to separate the hibernate config and the hibernate mapping for classes. Ideally, the hibernate config file should only contain the username and password for the database, and another file should contain the mappings for all the hibernate classes.

Context: See comment below in PR #30

Note: There is a slight change you would need to make to your local repo if this PR is merged. Currently, the project retrieves all hibernate configuration information from the hibernate.cfg.xml.private file which is based upon hibernate.cfg.xml.example, both of which are in novaweb/src/main/resources/config. The reason why the .private extension is used is because it flags the file as private, which lets Git know to never commit the file. This is important since the file contains secret information such as the database username and password. That is why during the initial clone of the repo, you must copy the .example config file to the .private file and add the username, password, and database URL.

Issue
Right now a user can input information into a text box on the Student Account page.
This information should be set and cannot be changed by the student.

Solution
Steps to reproduce the behavior:

1. Sign in as [email protected]
2. Go to 'Account'
3. Click 'Test'
4. Clicking 'Test' results in an option for user input

Expected behavior
Should not be able to enter information into the Student view of account.

Screenshots

Test cases need to be added to the project in the directory /src/test/. This will ensure the project is functioning as intended.

Feature

Solution

Description
The NOVA project specification states that there should be a way for users to self report their own status.

Solution
The backend functionality should be implemented to allow users to report their status. The user should be notified if their status was successfully reported or not.

Description
NOVA needs a way for users to add an emergency contact.

Solution
Each account will be capable of adding an emergency contact to their profile page.

Should an admin who is creating an account also include the emergency contact information?
I will for now add it to the profile page and see what my team thinks about the other option.