Release Notes: 2.45.0 Role Management

High-Level Summary:

Role based access control in MyVCM is HERE! This launch includes flexibility to build new roles according to your organizational needs. With the addition of the new custom roles, you can manage who can access which module on your MyVCM platform! 

 

Role Management Highlights: 

 

• Create new roles to manage the view in MyVCM without giving full Administrator access to every user.

 

• Protect the privacy of the teams that are managing different types of security assessments and stream like the process by reducing each team's view to align with their assessment tasks. 

 

• Your auditors can access any evidence attached to the assessment, even if it is a private artifact on the platform without exposing them to everything in your MyVCM account. 

 

• Allow your users to request access to private artifacts as needed.

Definition of system and artifact level roles in MyVCM:

• System level roles:
• Site Admin: The highest level role in MyVCM. It can create, modify, delete artifacts, view organization’s activity logs, manage billing and subscriptions.
• Admin: It can do everything Site Admin does except managing billing and subscriptions.
• User: It can view all of the artifacts, create and modify tickets, but can’t do anything else on the platform.
• Artifact level roles:
• Owner: It is the highest level role belonging to the artifact. It can  create, modify, delete the artifact.
• Custodian: It can do everything Owner does except deleting the artifact.
• Consumer: It can view the artifact, take action on the assigned tasks, such as approve/reject a document, download the training.

How to access the Role Management section in MyVCM:

 

• Role Management is available as another card under the current System Settings. 
• The card title is “Role Management Settings”. 
• When the admin/site admin clicks the “Configure roles” button, the system takes the user to the “Role management” page.

 

Role Management Table View:

 

• The default role management column headers are:
• Role name:

The role name should be a hyperlink and if clicked it takes the user to the new tab opening “view role” screen.

• Role type:

The role type options are “System” and “Custom”.

If the roles are Admin, Site Admin, User, then they are system roles.

Any other roles created by Admin/Site Admin would become custom roles. The custom roles are the ones that can be created from scratch by the “add new role” button or the ones that can be created by cloning an existing role by “clone and create new” button.

• Number of users:

This is the number of users assigned to the role.

The number should be a hyperlink and if clicked it opens the side drawer and displays the list of the users assigned to the role.

• Status:

The role status options are Active/Inactive.

• Created by:

The “Created by” column shows the name of the user who has created the role.

The user’s name should be a hyperlink and if clicked it opens the user pop-up that displays the quick user profile information (it should carry over the way it works currently)

• Created on:

The “Created on” column shows the date and time when the role has been created.

The role management table view (grid) should be ordered by this column (descending).

 

• Action: Add New Role

When the user hovers over to the orange + icon on the Role management table view (grid), the icon expands to the “+ New Role” button.

• When the user clicks the  “+ New Role” button, it should take the user to the new role page in edit view.
• The role title is named  “New role Mon DD, YYYY, H:MM am” by default. The user can rename the role, the role title text field is an editable field.
• New role edit view:
• All checkboxes under the Modules card should be unchecked.
• All cards should be “Off”.
• The “Save role” button should stay grayed out and unclickable until the user starts making changes on the settings. It will turn blue and become clickable then.
• If the “view” permission on the module is not checked inside a custom role, the user who is assigned to the role would still see the module as a menu item on the main navigation, but he/she can’t access anything other than the Pending/My tabs. 

 

• Action: Clone and Create New Role

• When the user selects the “Clone and create new” option under the role management table view (grid) row level actions under the vertical 3 dots OR from the gear icon on the view role page, it should take the user to the cloned role page in edit view.
•  The system should rename the close as [The original role name]_copy
• Clone’s edit view should carry over all the selections made on the original cloned role.

 

• Action: Change Role

• Change role does not affect the user assigned to the role because the user has not signed in yet and is not doing anything actively on the platform at the time of the change role action.
• Change role directly affects the user assigned to the role because the user can be in the module, in the artifact and at the time of the change role action, he/she loses the permissions to access it.
• The Admin/Site Admin’s point of view, who changes the role:
• This action can be initiated through;

The users table view (grid) row level actions under the vertical 3 dots:

• Change role: This option can be utilized to change a single user’s role to another role.
• When clicked, the “change role” pop-up appears and the new role can be selected. After the selection is made, the “Submit” button turns blue and allows the user to click.
• When the “Submit” button is clicked, the information message appears on the screen: “You'd like to change [First Name, Last Name]'s role from [X] to [Y]. If the user is on the platform and actively working on the artifacts, he/she has to log out and log back into the platform with updated permissions.  Do you want to proceed?” (Cancel/Proceed)
• When the “Cancel” button is clicked, the workflow ends without making any change to the user’s role.
• When the “Proceed” button is clicked, the confirmation message appears on the screen: “The user [First Name, Last Name]'s role has been changed from [X] to [Y] successfully.” (Close)

OR

• The users table view (grid) bulk action:
• Change role:  This option can be utilized to change multiple users’ role to another role.It will be activated only if the user checks the checkboxes next to the users table view (grid) rows. When the checkboxes are checked, the “Actions” button will become available on the top of the grid and “Change role” is the only option
• When clicked, the “change role” pop-up appears and the new role can be selected. After the selection is made, the “Submit” button turns blue and allows the user to click.
• When the “Submit” button is clicked, the information message appears on the screen: “Please be informed that changing the role from [X] to [Y] would affect the users assigned to the  [X] role. If the users are on the platform and actively working on the artifacts, they have to log out and log back into the platform with updated permissions. Do you want to proceed?” (Cancel/Proceed)
• When the “Cancel” button is clicked, the workflow ends without making any change to the users’ role, and the user is taken back to the users table view (grid).
• When the “Proceed” button is clicked, the confirmation message appears on the screen: “The users' role has been changed from [X] to [Y] successfully.”(Close)
• The user(s)’ point of view, who have the role been changed while they are actively working on the platform:
• The user would see the following information message on his/her screen as soon as their role has been changed: “Your permission settings have been changed by the platform administrator. Please click OK to log out and log back into the platform again.” (OK)
• As soon as the user clicks “OK”, the system logs him/her out of the platform.

 

• Action: Deactivate Role

• This action can be initiated through the Role management table view (grid) row level actions under the vertical 3 dots.
• When clicked, the “deactivate role” pop-up appears with the role that the user would like to deactivate is pre-selected. 
• When the “Cancel” button is clicked, the workflow ends without deactivating the role.
• When “Deactivate” is clicked:If there are not any assigned users to this role, the role is deactivated and the confirmation message appears on the screen. “The [X] role has been deactivated successfully.” (OK)
• The role status turns to “Inactive” on the role management table view (grid).
• After the role becomes inactive, “Activate role” option becomes available at the row level actions under the vertical 3 dots.
• If the user clicks the “Activate role” option, then the role status turns to to “Active” on the role management table view (grid) again and the confirmation message appears on the screen. “The [X] role has been activated successfully.” (OK)
• If there are already assigned users to this role, the role can’t be deactivated and the information message appears on the screen. “The role [Custom Role 2] cannot be deactivated because there are users assigned to this role. Please move the users to another role before deactivating this role.” (Close)
•  The workflow ends without deactivating the role and the user is taken back to the role management table view (grid).

 

• Action: Delete Role
• This action can be initiated through the Role management table view (grid) row level actions under the vertical 3 dots.
• When clicked, the “delete role” pop-up appears with the role that the user would like to delete is pre-selected. 
• When the “Cancel” button is clicked, the workflow ends without deleting the role.
• When “Delete” is clicked:
• If there are not any assigned users to this role, there is an alert message appearing on the screen with “Delete role?” as the title of the pop-up (Please do NOT use WARNING as the title anywhere):  “Do you want to proceed to delete the [X] role?” (Cancel/Proceed)
• The pop-up should have a simple text section, which is NOT a required field. If the user inserts a note, the note should be added to the activity logs.
• Then, if the user clicks the “Proceed” button, the role is deleted and the confirmation message appears on the screen. “The [X] role has been deleted successfully.” (OK)
• The role disappears from the role management table view (grid).
• If there are already assigned users to this role, the role can’t be deleted and the information message appears on the screen. “The role [Custom Role 2] cannot be deleted because there are users assigned to this role. Please move the users to another role before deleting this role.” (Close)
•  The workflow ends without deleting the role and the user is taken back to the role management table view (grid).

View Role page:

• The user can arrive at this screen by clicking the “View role” action under the vertical 3 dots on the role management table view (grid).
• If the viewed role is a system role:
• The system roles, such as Site Admin, Admin, or User, can only be viewed, they can’t be edited.
• The gear icon on this page would only allow “Clone and create new” action. 
• If the system roles are cloned, the new role out of the clone becomes a custom role. The new role cloned out of a system role can never be a system role.
• If the viewed role is a custom role:
• The custom roles can only be viewed and edited.
• The gear icon on this page would allow “Clone and create new” and “Edit role” actions. 
• If the custom roles are cloned, the new role out of the clone becomes a custom role. The new role cloned out of a custom role can never be a system role.
• “Back” button would carry the user to the Role management table view (grid).

Edit Role page:

• The custom roles can be viewed and edited.
• The user can arrive at this screen by clicking the “Edit role” action under the vertical 3 dots on the role management table view (grid) OR from the gear icon on the “view role” page would allow “Clone and create new” and “Edit role” actions. 
• The title of the role becomes editable when the user clicks on the title text field.
• When the role is in “edit view”, all of the checkboxes and toggles on the page should become selectable.
• “Back” button would carry the user to the Role management table view (grid).

 

Use Case: Request access to an artifact

• General information:

The users can request access to the artifacts that are not originally belonging to their permission level.

• Workflow:

The user’s side who requests access to the private artifact:

• The user who wants to view the private artifact would see the private artifact with the title “Private X” (X can be any artifact on the platform, such as an assessment, an asset, etc.) and an icon that specifies it is private next to it .
• The title has a hyperlink
• The user would receive the following message: “This is a private artifact. Please request for access.“ (Button: Request access)
• As soon as the user clicks the “Request access” button, the user sees the following message: “Your access request has been sent to the owner. You will receive a notification when it is approved or rejected.“ (OK)
• The user’s side who provides the access to the person who has requested to access:
• The user who is the owner of the artifact should receive an email notification.
• When the user clicks the “View Ticket” link on the email, it takes the user to the approve/reject ticket’s “Approval request” pop-up. On this pop-up the user can
• Approve request and add the user as the custodian of the artifact
• Tooltip: The user who has requested access to the artifact would be added as the custodian to the artifact. He/she would have the same permissions on the artifact as its owner.
• Approve request and add the user as the consumer of the artifact
• Tooltip: The user who has requested access to the artifact would be added as the consumer of the artifact.  He/she would be able to view the artifact but can’t have any more permissions on it.
• Reject request

 

Use Case: When a private artifact is added as an evidence to the assessment

• If a private artifact is added as evidence to the assessment by its owner, any user added to the assessment as the owner, custodian, consumer, auditor can view the private artifact.
• This is valid for any type of the assessments, including self-assessment, vendor assessment, and auditor assessment.
• This is valid for the requester-responder sides of the vendor and auditor assessments.
• Workflow:
• The user’s side who provides the access:
• When the owner of the private artifact wants to attach the private artifact as the evidence to the assessment, he/she should see this message on the screen:
• “You are trying to associate a private artifact as evidence to this assessment. Please note that the other users who have been added as the owner, custodian, consumer, or auditor to this assessment would be able to view those private artifacts.“ (OK)

 

Use Case: Custom Role - Assessment Manager

• What we are trying to accomplish:

Ability to allow auditors to send assessments to their clients but at the same time the auditors should not see each other's assessments. It is now possible with the newly introduced role management.

• The administrator/site administrator can create a new custom role and call it  “Assessment Manager” with the ability to create assessments.
• The users can be assigned to this role.
• Then, each user creates a private assessment that they can send to their clients and/or vendors. The assessments should be switched to “private” in order to make this use case work.
• When they go to the Assessments table view, they can see the other assessment is listed there. However, they can’t see the content of it without requesting access permission.