Secure Field Level Access

ccppmop158
HID_secure_field_level_access
You can now secure fields to ensure only specific groups of users can access specific fields or attributes.
As a blueprint administrator you need to configure all the secured attributes for ideas or projects in blueprints and display or hide them based on the access rights. You can display or hide specific fields in ideas or projects at the group level. All users who belong to the specific group, can access the secured fields. However, as the administrator, you can view all the attributes when you configure blueprints.The secured fields are distinguished with an () icon. The new field level security feature lets you provide users with access to secured fields and hide them as necessary. Users who have access to the secured attributes, can view them in both ideas or projects board and grid view.
Important!
  • Field level security always takes precedence over Instance, or OBS, or Global rights in a project or idea.
  • Field level security is applicable to both ideas and projects.
  • Field level security is
    not
    applicable to Hierarchy.
Example:
Jennifer - a product manager knows product budgeting, has visibility into customer insights, is responsible for product features, and team management. An expert at product planning, she knows how to maximize return on investment.
Jennifer observes that some of the ideas have the potential to be converted into projects to add value to their organization. However before the ideas are converted Jennifer needs Rita's financial expertise to project the estimated cost of the ideas before she can submit the ideas for approval.
Jennifer provides Rita with the Access Edit and Access View rights for Rita to be able to view and edit the cost plan details and submit the plan for approval.
Mike - the project contributor is responsible for the smooth operation and progress of the teams. Mike has access to all his teams’ ideas and timelines. He can view the ideas details such as cost plan, and budget plan and other such details to be able to coordinate among stakeholders, plan, prioritize, and regulate the progress of the work being done in his business unit.
However Mike does not need the right to edit any of the details. Nicole provides Access View rights to Mike for him to be able to view and coordinate among all teams.
This section contains the following topics:
2
Prerequisites
The following rights are required to access secured fields:
  • You must be belong to the PMO System Administrator group.
  • Ensure that you have the
    Attribute management – Navigate
    right. This right allows you access to the Attributes management page in the new user experience. You can view information related to attributes, and configure attribute security using access groups and see the
    Attributes
    tile in Administration workspace. The Attributes page displays the Attribute generic grid with all attributes of all objects.
  • PMO Persona Group - Must have
    FLS-Edit
    access rights on the
    Template and Assignment Pool
    attributes to edit or set a project as a template.
  • Any other End-User Persona Group - Should have
    FLS-View
    access rights on the
    Template and Assignment Pool
    attributes to create projects using templates.
  • Any End-User or Group who do not have FLS access to
    Template or Assignment Pool
    cannot do the following:
    • Set a project as a template
    • Create projects using a template.
  • To Convert Idea to Project – Users must have either
    View
    or
    Edit
    access to
    Template
    attributes. Without access users cannot convert ideas to projects.
  • If the attribute is set to
    required
    and a user has only
    FLS view
    access, the user cannot edit the value of the attribute when creating a project or idea instance.
  • The system should not allow you to specify the values for required or non-required attributes that have
    FLS View
    only access rights while creating a new instance.
Configure Secure Attributes
Follow these steps:
  1. Navigate to
    Administration
    , click
    Attributes
    .The Attribute page opens, all the attributes for all objects are listed in this page.
  2. Click the checkbox in the
    Secure
    column to set the corresponding attribute to secure. The following conditions apply if you set the Secure flag to:
    • False - All users can access this attribute.
    • True - Only users who belong to select groups can access the attribute.
    • True - and if no group access is set, the attribute cannot be accessed by anyone.
      Note:
      If you set the Secure flag to true, the system does not set any group automatically.
  3. Select a row and click
    Details
    . The Details fly-out window opens.
  4. Specify the
    Access Edit
    and
    Access view
    groups.
All users who belong to the specific group can view or edit the attribute based on the access provided. You can configure access independently for the same attribute on different investment types. If an attribute is used in a project and the same attribute is used in an idea, the attribute can be configured to secure in just one of the objects.
If the attribute is_template is set to
Secure
and no access rights are provided, the system will not let you create a project using the option
New From Template
.
Scenarios and Exceptions
After you implement field level security note the following scenarios and exceptions:
Blueprints
  • As a Blueprint administrator you should be able to view all the secure and non-secure attributes when you configure the Blueprint for Projects or Ideas.
  • If a user does not have any access rights to all the secured fields in Preview mode, hide the section from Blueprint.
  • If a user has access to at least one of the attributes within the section, then the section should be displayed in Preview mode.
  • If a user has access to secured fields in a section, the user should be able to view the fields.
  • If a user does not have access to secured fields within a section, the user cannot view the secured fields in Preview mode.
Projects or Ideas Details Panel
  • If a user has access to secure fields, the user should have access to the fields from the Details panels as well.
  • If a user does not have access to secure fields, the user should not have access to the fields from the Details panel as well.
  • If a user does not have access to secure fields, the user should not be able to view them in the Details Page. A blank label must be displayed.
  • If a user does not have access to secure fields, the user should not be able to fetch the secure fields using REST API GET/POST/PATCH calls.
Secured Fields in Projects or Ideas Grid
Users can either view or edit the secured fields based on their access rights. The following conditions apply:
Functionality
Users with access to secured fields
Users without access to secured fields
Grid Layout
Secure fields are accessible from the grid layout.
Secured fields are inaccessible from grid layout.
Grid Filter
Users can filter the secured fields from the grid filter.
Users cannot access the secured fields from the grid filter. If users open a saved view with a filter that contains a secured field, they can only see an unsaved view.
Group By
Users can view the grid data that is grouped by a secured field from a saved view.
Users cannot view data from a saved view that is grouped by a secured field. The user sees an unsaved view.
Column Panel
Users can view the secured fields from the column panel.
Secured fields are not visible from the column panel.
Export to CSV
Users should be able to export CSV file with secure attributes.
Users cannot view the secured attributes to download the related CSV file.
Secured Fields in Projects or Ideas Board View
The following conditions apply basis the access provided to users for secured fields in projects or ideas board view:
Functionality
Users with access to secured fields
Users without access to secured fields
Secured field in a saved view
User can view the saved view.
A message appears indicating that a field is unavailable and displays an unsaved view.
Card title for a saved view that contains a secured field
User can view the card.
User can view the card, the title of the card displays blank.
If a column is set to secure
User can view the column.
The column title is set to none.
Color By
User can view the secured field in the set color.
The view option for color by is cleared out and set to none.
Card Fields
User can view the fields in the card.
The view option for the card fields is cleared out.
Card Metrics
User can view the card metrics.
The view option for the card metrics is cleared out.
Saved View
User can view the secured fields.
User sees an unsaved view ( without secure fields).
If you have saved a view in a project or idea and your administrator secures some of the fields, if you do not have access to the secured fields and open the saved view, a message appears and the view goes into an unsaved state.
Impact and Exemption in Field Level Security
Some areas are impacted and some areas are exempted as you implement field level security. This section describes all the exceptions.
Hierarchy
  • Hierarchy is
    exempted
    from field level security. Only during the import of project & idea grids are displayed and you can view the secure attributes in the grid.
  • While importing projects or ideas into hierarchy, you will see the same saved view as you see when you access the projects grid, ideas grid, or any custom investment grid. You can select any existing saved view, or create a new saved view that is also available when you navigate to the grid layout of a specific workspace. Field level security is applicable in the selection grid, just as in ideas or projects grid.
  • Field level security is applicable to aggregated metric attributes in hierarchy.
Attribute Exceptions
The following attributes are exceptions where field level security cannot be implemented:
  • Project Object:
    • Name
    • Investment ID
    • Start
    • End
    • Blueprint Active ID
  • Idea Object:
    • Subject
    • ID
    • Start Date
    • Finish Date
    • Blueprint Active ID
  Non-Impacted Areas
The following areas are not impacted if you implement field level security:
  • Clarity Classic UI
    • Studio
      • Objects
      • Views
      • Portlet Pages (Including secure sub-pages)
      • Portlets
      • Queries and Data Providers
    • Reports and Jobs
    • Audit Trail
  • Open Work Bench (OWB)
  • Microsoft Project (MSP)
  • XML Open Gateway (XOG)
  • GEL Script that do not call REST APIs
  • Processes
  • Data Warehouse and HDP
Third Party Integration
The following integrations are impacted if you implement field level security:
  • Rally - Field level security is applicable and can be implemented with Rally. If you have access to secure attributes, you can pass the attributes and their value to Rally.
  • GEL Script calling REST APIs –Any integration should have access to the attributes either view or edit, so that the REST APIs can communicate with the third party application or software.