Secure Field Level Access

ccppmop1591
HID_secure_field_level_access
You can now secure fields to ensure only specific groups of users can access specific fields or attributes.
As an administrator, you can implement Field Level Security in
Clarity
to ensure you provide access to specific attributes or fields for specific user groups in Projects, Ideas, Custom Investment Items, and Custom Objects. Users who have access to the secured attributes can view them in both board and grid views. Although the field level security feature lets you display or hide fields from specific user groups, as an administrator, you can view all the attributes when you configure the Blueprints.
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.
  • Field level security is not applicable to TSV attributes in
    Clarity
    .
Example - Projects and Ideas:
Jennifer - a product manager who understands 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 figure out 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 the financial attributes so that Rita can edit 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 details of the ideas 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. Jennifer provides Access View rights to Mike for him to be able to view and coordinate among all teams.
Example - Custom Investment Items:
Sid – a portfolio manager is responsible for creating, editing, and managing Custom Investment Items for his organization. While creating a Strategy and defining its Objectives, Sid adds the Estimated Budget Plan attribute using the Strategy Blueprint. Sid provides his stakeholders with the Access Edit and Access View rights. The stakeholders can now review and update the Estimated Budget Plan for their Strategy. After the Estimated Budget Plan is finalized for the Strategy and the Objectives are defined. The Strategy and the Objectives can now be shared with the team members for assigning the tasks and estimating the timelines. Since the team will only need to view the Estimated Budget Plan details, Sid shares the Objectives with the assigned staff and provides just Access View rights to the team.
This section contains the following topics:
2
Prerequisites
The following rights are required to access secured fields:
  • You must 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
    Clarity
    . 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.
  • When you are creating a new Custom Investment instance, the system should not allow you to specify the values for required or non-required attributes that have FLS View only access rights.
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, or Custom Investment item, 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, Ideas, or Custom Investment Items.
  • 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.
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 is 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 Grid Layout
Users can either view or edit the secured fields from Projects, Ideas, Custom Investments, or Custom Objects grid 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 the CSV file with secure attributes.
Users cannot view the secured attributes to download the related CSV file.
Secured Fields in 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
Saved View
User can view the saved view.
A message appears indicating that a field is unavailable and displays an unsaved view.
Card Title - The 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.
Column - If a column is set to secure
User can view the column.
The column title is cleared and set to none. The ‘
None’
column appears with the data.
Column Tab
User can view the column tab.
The Column tab on the right side of the page is not visible as there are no columns to hide or show.
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.
View – If a view is changed and contains secured fields.
User can view the secured fields.
A message appears and the view changes into an unsaved view (without the secured fields).
Consider a scenario where you have saved a view in a Project, Idea, Custom Investment, and Custom Objects then 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
Clarity
displays an unsaved view.
Impact and Exemptions
This topic describes all the exemptions and impact when you apply field-level security in Ideas, Projects, or Custom Investment Items.
Hierarchy
  •   Field level security is not applicable in Hierarchy. When you import Projects, Ideas, or Custom Investment Items, you can view the secured attributes in the grid.
  •   When you import Projects, Ideas, or Custom Investment Items, into Hierarchy, you will see the same saved view as you see when you access the Projects, Ideas, or Custom Investment Items grid. You can select any existing saved view, or create a new saved view when you navigate to the grid layout of a specific workspace. Field level security is applicable in the selected grid, just as in Projects, Ideas, Custom Investment Items, and Custom Objects 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
  • Custom Investment Object:
    • Subject
    • ID
    • Name
    • Start Date
    • Finish Date
    • Blueprint Active ID
Non-Impacted Areas
The following areas are not impacted if you implement field-level security:
  • Classic PPM
    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.