V2 User Management

V2Master

Document History

  1. 2013.11.11 - JK
  2. 2013.11.11 - JK
  3. 2013.11.12 - AH/TN

Terminology

Definitions:

  1. Roles - refers to project roles, not user privileges (e.g. access rights)

  2. Code - Use Code or Short Code = abbreviation

  3. Folder - Folders for storing objects

  4. Privileges - refers to system access privileges, e.g. permissions for accessing and updating data in the system

  5. Object (should this term ever be used in business domain?)

Business requirements

  1. Ability to assign a user to a folder:
    1. Objects (e.g. Users) can only be assigned to a single folder

    2. Configuration notes: Create a sub-branch Personnel Resources somewhere in the PM branch of the WBS and create a folder (at bottom level) Team Members

    3. If necessary, have a Team Member folder for each company

  2. Ability to assign classifications to users
  3. Ability for V2 administrators to add users easily, without having to wait for email confirmations:
    1. The permission to do this should be be granted on a folder basis, allowing delegation of user management to sub-folder trees.
    2. E.g. administrative users would be able to manage users assigned to folders they are allowed to administer. They would only be able to grant permissions within those sub-folder trees.
  4. Ability for V2 administrators to change and correct user details stored in the V2 database:
    1. E.g. project role description, Skype name, phone numbers, company, subject to the restrictions described above
  5. Ability for users with appropriate roles to add transmittal recipients, who could be normal system users or external users, to the system easily and without having to wait for an email confirmations.
  6. Use a flag field in the database for marking external users (separate from the disabled flag)
    1. Most likely the recipient users would be registered in the V2 database users table, but not in the MAPS database. The recipient users would not have a login role, and therefore no access to the system beyond that offered by the transmittals are sent.
    2. Note that normal system users can be transmittal recipients.
  7. Ability for a user to change (some?) of their user information themselves, including:
    1. Primary email address
    2. Add/remove additional email addresses
  8. Ability for administrators to disable/enable users. A disabled user will:
    1. not be able to login to the system.
    2. not be sent transmittals
    3. not appear in user select lists
    4. not appear in user lists, by default
  9. It will not be possible to delete users from the system, as audit trail and workflow records will refer to them.

    1. Question: Could it be possible possible to delete 'new' (never used) users, for whom no audit trail or workflow records exist?

      1. Yes, provided there is absolutely no history for the user.

    1. Ability to make a list of users. Able to differentiate the following:
      1. Enabled users
      2. Disabled users, not displayed by default
      3. Recipient only users
    2. Ability to search for users in specific folders and sub-folders
    3. Ability to to search for users meeting specific classification criteria

MAPS/V2 Integration

  1. A V2 administrator will not be able to alter any user information or email addresses stored in MAPS (except that associated with their own user record)

    1. Question: Does this mean that different user data might be stored in MAPS and in V2?

      1. MAPS only stores: first name, last name, company (all text fields) and email addresses. There is no requirement that the name and company fields match between V2 and MAPS.
  2. The V2 system can operate in either SSO or local sign-on mode

  3. In SSO mode there will be information shared between MAPS & V2

MAP/V2 Coordination Issues

  1. How to propagate user and email updates in MAPS to V2?

    • Question: Is it necessary to be able to propagate user and email updates?

  2. How to propagate user and email updates in V2 to MAPS?

    • Question: Is it necessary to be able to propagate user and email updates?

Usability Review

Project -> Users -> List

  1. Rename Users to Project Team in upper banner menu, since external recipients will be included (non-users as they will not have login) canned to use project management terminology

  2. Rename User List to Project Team List

  3. Need to solve duplicity between Project Role, as now assigned to users as system metadata, and Project Position, as assigned by Project Organisation (OBS) classification:

    1. Project Role should preferably be assigned as per Project Organisation (OBS) as this will in future be used to assign responsibilities and access privileges (by using OBS nodes); OBS will presumably be moved to Project -> Structures in a future release (currently configured as a classification field)

    2. Project Role as currently implemented (in User List, User Detail) should be moved to classifications (as configured for Project)

  4. Need to consider project team in organisation chart versus other project participants (or system users), such as system administrators, proposal team, company management, etc., (many of whom will also require a system login)

    1. Note: This can be solved using classification object categories

    2. OBS should therefore not be a required field for "other project participants"
    3. The project function of "other project participants" should be stated in a description field
  5. Allow and display user classifications including configuration of list and detail (analog to documents)
  6. Remove fields Office Phone, Mobile Phone, Skype Name. They can be implemented as classification fields (as configured for Project)

  7. Classification fields which include data should be moved into a new Data Block (or "Properties Block") block (JK: OR SUB_BLOCK?) just below the Identification Block, which will be so indicated in the classification configuration screens)

  8. System data fields for users will be: First Name, Last Name, Initials, Email Address, Company. The Company field to be a text field (informational)

Project -> Users -> New

  1. To be added (currently it is only possible to add users using invitations), need to be able to add e.g. external users for sending Transmittals (without invitation) [P1]
  2. To consider initial configuration (and later incrementation of this) where many users will be added at one time. Preparing an invitation for each user will require too much initial effort. [after P1]

Project -> Users -> Profile

Comments based on Profile as currently displayed for user who is logged into system

  1. To be added (currently it is only possible to see detail for user who is logged into system)
  2. List from "User Profile" to Team Member Profile"
  3. Quick Links, some of the items should be moved to an administrator screen
  4. Is email address in a separate table? It can be included in User Profile.
  5. Rename block title "User Details" to "Profile"

Project -> Users -> Profile -> Edit

  1. To be added (currently it is only possible to see detail for user who is logged into system)

Project -> Users -> Access Privileges

  1. Changing axis of table to show users horizontally (best as collapsible OBS presented similar to Folder) displaying individual names of team members (users) at applicable nodes, and displaying Folder (e.g. WBS) vertically [P3]

  2. Include Project Role from OBS next to Name in configuration table [P1]

Folder Permissions

  1. Folder access privilege choices Privileges are currently: NULL, read, update, admin

  2. Change to:

    1. NULL

    2. Informed

    3. Collaborate

    4. Interface

    5. Responsible

    6. Approve

    7. Admin

Permission Levels

Notes

  1. View - Ability to list and view

  2. Upd. - Ability to create, update and delete

  3. Shar. - Limited to shared files and notes

    1. View access restricted to shared files and notes
    2. Update and delete access limited notes and files in their own name
    3. Create limited to items in their own name

  4. All - View, Update and Create access to all files and notes (e.g. both shared and restricted)

More Notes (JK)

1. The above permissions table should be displayed under Project -> Configuration -> Access Privileges

1. The Access Privilege table would ideally by configurable. Access Privileges are however very likely to be discarded during R2 (workflow) development and replaced by a responsibilities assignment matrix with implied access privileges. Therefore hold on any further work.

Issues

  1. Who can create and update revision metadata?

    1. Specifically can Interface

      1. Create new documents/revisions? JK: NO (ONLY COMMENT)
      2. Update document metadata (specifically for documents that have revisions that are locked) JK: NO (CAN COMMENT - after commenting implemented)
  2. Who can delete documents, tasks, users, etc?

    1. Probably only with Approve or Admin privilege once document, task or user is locked

  3. How to determine when objects should be locked?

V2UserManagement (last edited 2014-02-25 13:59:35 by gw)

Copyright 2008-2014, SoftXS GmbH, Switzerland