PROJECT: Incident Management System

Overview

The Incident Management System is a desktop application used for managing incidents and dispatching vehicles. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has about 10 kLoC.

Summary of contributions

  • Major Enhancement: Implemented Access Control

    • What it does: Restricts usage of the product to registered users, with additional command restrictions depending on user access level.

    • Justification: This feature improves the product significantly by implementing basic security controls. Since the product is meant to deal with management of physical resources (vehicles) and sensitive information (incident reports), security controls are necessary for accountability and protection against misuse.

    • Highlights: This complex enhancement affects existing commands and can be easily applied to any commands added in future. It required an in-depth analysis of the product architecture, logic, and design alternatives. The implementation too was challenging as it required thorough assessment of loopholes and potential security vulnerabilities.

  • Minor Enhancement: Implemented Account Management

    • Summary: Allows users the ability to manage their own account or other accounts if granted privileged access. This feature is necessary for the effective application of access control.

    • Highlights: This enhancement required extensive overhauls of existing code, along with in-depth analysis of the GUI design for its implementation.

  • Code contributed: [View on RepoSense]

  • Other contributions:

    • Project Management & Team Tasks:

      • Managed releases v1.1 - v1.3 (3 releases) on GitHub

      • Implemented the Session API for all developers to access account features [#66]

      • Morphed Person Model to deal with new Account Features [#48]

      • Refactored Address Book references to Incident Manager [#111]

    • Tools & Enhancements to existing features:

      • Integrated new Github plugins (Coveralls & Codacy) to the team repo

      • Improved the GUI to function in varying screen resolutions [#69]

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Access Control feature

Implementation

The access control feature is centered around three core concepts:

  1. Command Restrictions: Restriction of access to commands until after identity is verified

  2. Identity Verification: Verification of identity via unique credentials and a confidential key

  3. Account Management Restrictions: Access level restrictions for commands affecting other accounts

Command Restrictions

Prior to login, the user is only granted access to the login, register, help, and exit commands. This is achieved via a guard statement in the IncidentManagerParser checking whether the user is logged in or the command created is an approved command that doesn’t require login.

The guard statement throws a command exception and informs the user of the available commands prior to login.

Activity Diagram for illustration:

AccessActivityDiagram
Identity Verification

Users are required to login via the Login command with a Username and Password. See user guide for more details on the command syntax for Login. Users are also allowed to Logout and thus end their Session.

Session details are displayed on the status bar in the GUI to reflect whether a user is logged in, and the username as well as time logged in if a user is logged in.

Class Diagram for illustration:

SessionClassDiagram

Uniqueness of a username is ensured by preventing duplicates during the account creation [RegisterCommand] and account update [UpdateCommand] processes. The respective commands will check the list of accounts in the model and throw an exception if a duplicate is found.

Account Management Restrictions

To prevent abuse (e.g. adding a dummy account and editing/deleting other accounts), all new accounts are differentiated from Admin accounts. This restriction based on access level is implemented via account Tags:

  • Only a Person with an admin Tag can access account management features. Such a person will henceforth be referred to as an Admin.

  • Users who are not admins are not allowed to add tags (via both RegisterCommand and UpdateCommand).

  • Only Admins are allowed to edit or add tags (via both RegisterCommand and UpdateCommand).

Non-admins can still edit their own account details via the UpdateCommand. Refer to user guide for more info.

Additional access restrictions:

  • Only admins can update an account that is not their own.

  • Only admins can access the delete command.

  • Admins cannot delete their own account.

  • Admins cannot 'downgrade' themselves by removing their own admin tag.

The checks described above all function in the command execution stage. The RegisterCommand, UpdateCommand, and DeleteCommand retrieves the logged in Person from the Model via utilisation of the Session.

Simplified Sequence Diagram for illustration:

AccessSequenceDiagram
The lifeline for DeleteCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of the diagram.

Design Considerations

Aspect: How Command Restrictions are Managed

  • Current Choice: Guard statement in IncidentManagerParser prior to Command Creation.

    • Pros: Early catching of restriction, command doesn’t get instantiated unnecessarily. Better user experience as error message is displayed early.

    • Cons: Need to expose model to parser as session is managed by model, increasing coupling.

  • Alternative: Guard statement in LogicManager prior to Command Execution.

    • Pros: Model does not need to be exposed to parser as it is already managed by command execution, decreasing coupling.

    • Cons: Command still gets instantiated, memory allocated to command creation. Decreases user experience as user still has to type a proper command before the access error is thrown.

Aspect: How Identity Verification is Managed

  • Current Choice: Unique username and password.

    • Pros: Easy to implement.

    • Cons: Sufficiently advanced users can access the data file directly to retrieve user passwords.

  • Alternative: Physical security USB dongle.

    • Pros: Secure individually identifiable token.

    • Cons: Prone to loss and potential duplication. Hard to implement.

Aspect: How Account Management Restrictions are Managed

  • Current Choice: Utilisation of Account Tags

    • Pros: Easy to implement.

    • Cons: Easy to exploit, requires additional restrictions (e.g. users cannot add tags unless they are an admin).

  • Alternative: Addition of an Admin account attribute.

    • Pros: Distinct object class, improves cohesiveness.

    • Cons: Hard to implement.

Known Issues

A sufficiently advanced user can access the data file directly to manipulate account details. Data file encryption (to be implemented in v2.0) will resolve this issue.

Account Management feature

Implementation

The account management feature functions as a suite of commands available to the user. The commands available as part of this suite:

  • Register Command - Creates a new user account.

  • Update Command - Edits a user account. Not including an index updates your own account.

  • Delete Command - Deletes a a user account. Not allowed to delete your own account.

  • List Persons Command - Lists all user accounts or those whose tags match the user input.

  • Find Persons Command - Searches for user accounts based on matching name or username keywords.

  • Swap Command - Swaps GUI interface between account management and incident management.

Users are restricted from accessing commands affecting objects not on display. They need to invoke Swap to access the different command suites.

Only Admin accounts can access the full suite of account management features. See access control feature for more information. Non-Admins only have access to Register, List, Find, and Swap commands, as well as Update for their own account.

In the code base, Persons represent user accounts. See person model for more information.

Design Considerations

Aspect: Interface Implementation

  • Current Choice: Utilising a swap command that transitions between two distinct interfaces.

    • Pros: Distinct difference in command suite utilisation (account vs incidents), giving users a much cleaner distinction of what’s being managed, improves user experience.

    • Cons: Hard to implement.

  • Alternative: Having account information display alongside incidents and vehicles in a separate pane.

    • Pros: Easy to implement.

    • Cons: User might be overloaded with information in one screen, and text might get truncated in lower resolutions, decreases user experience.

Aspect: How Update executes

  • Current Choice: No index indicates own account update

    • Pros: Improves user experience, user does not need to look for their own index.

    • Cons: Susceptible to user error.

  • Alternative: Select index of own account for update

    • Pros: Easy to implement.

    • Cons: Decreases user experience, user will first need to find their own index.

Aspect: How Tag searching executes

  • Current Choice: Adding keywords after the list command performs a search

    • Pros: Does not require argument prefixes, improves user experience.

    • Cons: Decreases system cohesiveness as searching is performed in two separate commands.

  • Alternative: Utilising find command to search for tags

    • Pros: Centralise all account search operations in one command, improves system cohesiveness.

    • Cons: Requires the addition of argument prefixes, decreases user experience.

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Logging in: login

Logs the user into the IMS and registers the active session.
Format: login u/USERNAME w/PASSWORD

The only commands available prior to login are register, login, help, and exit.

Example:

  • login u/Agent01 w/password

Logging out: logout

Logs the user out of the IMS and closes the user’s session.
Format: logout

Swapping interfaces: swap

Swaps the user interface between account view and incidents/vehicle view.
Format: swap

A user cannot access commands affecting entities not displayed in their current interface view.

Account Management Interface:

account

Registering an account: register

Registers an account into the Incident Management System
Format: register n/NAME p/PHONE_NUMBER e/EMAIL u/USERNAME w/PASSWORD [t/TAG]…​

A account can have any number of tags (including 0). Only logged-in admins can add tags.

  • Usernames must be at least 3 characters in length and must be unique.

  • Usernames can only consist of alphanumeric characters and the following special characters, excluding the parentheses, (.-)

  • Usernames cannot begin or end with a non alphanumeric character.

  • Usernames and Passwords cannot be blank or contain a whitespace.

  • Passwords must be at least 6 characters in length.

  • Passwords can only contain alphanumeric characters and/or these special characters, excluding the parentheses, (!#$%&'*+/=?`{|}~^.-)

Examples:

  • register n/John Doe p/98765432 e/johnd@example.com u/op1 w/password

  • If logged in with an admin account:
    register n/Betsy Crowe e/betsycrowe@example.com u/oc1 w/password p/1234567 t/Team-1-OC

Updating an account : update

Updates an existing account in the incident Manager or the own account of the user logged in if the index is left empty.
Format: update [INDEX] [n/NAME] [p/PHONE] [e/EMAIL] [u/USERNAME] [w/PASSWORD] [t/TAG]…​

Only admins can update other user accounts. Non-admins cannot specify an index when executing the update command.

  • If an index is not provided, update executes on the account of the user logged in.

  • If an index is provided, updates the account at the specified INDEX. The index refers to the index number shown in the displayed account list. The index must be a positive integer 1, 2, 3, …​

  • At least one of the optional fields must be provided.

  • Existing values will be updated to the input values.

  • When updating tags, the existing tags of the account will be removed i.e adding of tags is not cumulative.

  • Only admins can access and edit tags. Admins cannot remove their own admin tag.

  • You can remove all the account’s tags by typing t/ without specifying any tags after it.

Examples:

  • update p/91234567 e/johndoe@example.com
    updates the phone number and email address of the logged in account to be 91234567 and johndoe@example.com respectively.

  • update 2 n/Betsy Crower t/
    updates the name of the 2nd account to be Betsy Crower and clears all existing tags.

Incident Auto Update [coming in v2.0]

Any updates to user account details will search for all incidents created by the account and update those references as well.

Listing accounts : list-a

Shows a list of all accounts registered in the incident Manager or those whose tags match any of the keywords if a keyword is specified.
Format: list-a [KEYWORD] [MORE_KEYWORDS]

  • The search is case insensitive. e.g admin will match Admin

  • Only the account tags are searched.

  • Only full words will be matched e.g. ad will not match admin

  • Accounts matching all keywords will be returned (i.e. AND search).

Examples:

  • list-a
    Displays the entire list of accounts

  • list-a team-1 admin
    Returns a list of all accounts that have both the admin and team-1 tag

Locating accounts by name or username: find-a

Finds accounts whose name or username contains any of the given keywords.
Format: find-a KEYWORD [MORE_KEYWORDS]

  • The search is case insensitive. e.g hans will match Hans

  • The order of the keywords does not matter. e.g. Hans Bo will match Bo Hans

  • Only the name and username is searched.

  • Only full words will be matched for Names e.g. Han will not match Hans

  • Partial words will be matched for Usernames e.g. Agent will match Agent01

  • Accounts matching at least one keyword will be returned (i.e. OR search). e.g. Hans Bo will return Hans Gruber, Bo Yang

Examples:

  • find-a John
    Returns john and John Doe

  • find-a Agent01 Betty Returns all accounts with username or name matching either agent01 or betty

Deleting an account : delete-a

Deletes the specified account from the incident Manager.
Format: delete-a INDEX

  • Deletes the account at the specified INDEX.

  • The index refers to the index number shown in the displayed account list.

  • The index must be a positive integer 1, 2, 3, …​

Only admins can access the delete command. You cannot delete your own account.

Examples:

  • list-a
    delete-a 2
    Deletes the 2nd account in the Incident Manager.

  • find-a Agent01
    delete-a 1
    Deletes the 1st account in the results of the find command.

Incident Auto Update [coming in v2.0]

Deleting a user will search for all incidents created by the user and place a deleted flag next to the account details.