Menu Close

Security Administration

Sites

Most affiliates are not utilizing sites in Atlas. The few affiliates that implemented sites are using sites to different extents.

BWH

BWH restricts access to interactions by site affiliation: BWH or BWH-IPC. To support this security model, the following rules apply when managing application users:

  • All application users must have a default site.
    • This ensures that interactions are added with a site. Users are trained to change the default site on interactions, if necessary.
    • This also results in most record types being tagged with the default site of the users who added them.
    • Sites on records other than interactions can be used for reporting and filtering, but they are not used to control record access.
  • The Interactions role must be assigned with a site restriction (Record access = Records with one of these sites assigned). There are a few users that require access to all interactions. In these cases, the Interactions role can be assigned with both sites or with no site restriction (Record access = All records).
  • The Constituent Add role must be assigned with both sites, i.e. Record access = Records with one of these sites assigned: BWH and BWH-IPC.
    • This ensures that both sites are added to constituents, which enables all users, regardless of their site restriction, to add interactions to constituents.
    • Assigning Constituent Add with access to “All records” prevents users with site restrictions from adding interactions.

PCC

PCC uses sites only for filtering and reporting by entities in their network. Most notably, they use sites on fundraising purposes and appeal records. There are no security requirements related to PCC’s sites.

CDHC

Implementation of sites is TBD as of August 2020. Similar to PCC, CDHC plans to use sites for filtering and reporting purposes. There are no security requirements related to CDHC’s sites.

Security Role Maintenance

  • Do NOT import security roles exported from one affiliate database into another affiliate database. This will wipe out all affiliate-specific permissions, such as attributes and smart fields.
  • When new features, tasks, and other securable entities are added to Atlas, they must be granted in at least one security role unless only System Administrators should have access to the entity. Refer to the table below for a list of securable entities.
  • Always grant access to new entities in the appropriate role AND Affiliate Admin unless only System Administrators should have access to the entity.
  • Add new entities to only one role other than Affiliate Admin. There are some exceptions to this rule (e.g. IPC Base includes several features that also exist in other roles), but this best practice should be followed whenever possible. Otherwise, access and restrictions (such as site security) can become more difficult to control.
  • Security Roles will be managed by the Mass General Brigham Development Office. This will make it easier to provide support for Atlas Security.  
    • To create a new Security Role, log a ticket in Mojo. A new Security Role will typically not require any additional approval, though it may be presented to the Design Team for input.  
    • To modify a Security Role, log a ticket in Mojo. Modifications to Security Roles will require Design Team approval. 
EntityWhere to Find It on System Roles
Features and tasks related to customizationsTasks and Features tabs
Features and tasks included in standard Blackbaud releasesTasks and Features tabs
Attribute categoriesAttribute Categories tab
Attribute query views for new attribute categoriesFeatures tab > Attribute Query and BBDW Query folders
Code tables (commonly added for new attribute categories)Code Tables tab
Smart field instancesSmart Fields tab
KPI instancesKPIs tab
Recognition program query views for new recognition programsFeatures tab > Constituent\Recognition folder
User-defined data listsFeatures tab > Query\User-defined Data Lists folder
User-defined smart query definitionsFeatures tab > Query\User-defined Smart Queries folder

 

Determining Existing Security Role Permissions

You can check existing permissions for a security role from the tabs on the role, i.e. Tasks, Features, Code Tables, etc. It is also possible to confirm permissions for most features and tasks by searching for the feature or task:

  1. Go to Administration > Application > Features.
  2. Click the Task search or the appropriate feature search.
  3. Search for and select the task or feature.
  4. Under Tasks in the left column, click Assign permissions.
  5. From the Assign permissions form, you can determine which in roles the task or feature has been permissions and add or move permissions to a new role.

You are unable to view or change permissions for some features through the feature page:

  • Search lists
  • Smart query definitions
  • Smart fields
  • KPIs
  • Business processes
  • Simple data lists
  • Batch types

Securing Business Process Instances

The majority of business processes are only accessible by Affiliate Admins and System Administrators. In the case that another role grants access to a business process area, it is strongly recommended that business process instances be restricted by security role. For example, the Gift Processing Manager role grants access to to Queues in Administration, but Gift Processing Managers only have access to the Post to GL queue. All of the nightly queue processes are restricted to Affiliate Admins.

Notable business process areas that are granted in roles other than Affiliate Admin include:

  • Queues – Gift Processing Manager role
  • Global changes – Global Changes role
  • Import – Batch and Import role

Affiliate Admins have the ability to set permissions on business process instances. To set permissions on a business process instance:

  1. Go to the list of business processes (e.g. Administration > Global changes).
  2. Click the caret next to the business process instance.
  3. Click Assign permissions.
  4. Under This feature is available for, select Selected roles.
  5. Select Affiliate Admin and click Grant.
  6. If another role requires access to the business process instance, select that role and click Grant.
  7. Click Save.

Troubleshooting Tips

IssueTry This
User does not see or cannot access a query or export*Check all fields and ensure that the user is assigned to the roles that GRANT access to all query views included in the query or export.
*Ensure that the user is not assigned to a role that DENIES access to one of the query views included in the query or export, e.g. Solicit Codes, Constituencies
*Check the permissions set on the query or Information Library folder
User gets the error "The current user does not have rights to use this form" even though they have been granted access to the form*Ensure that user has permissions to access all features nested in the form, e.g. search lists, view forms. See "Last Resort" Security Troubleshooting Steps " for more details.

“Last Resort” Troubleshooting Steps

In most cases, security issues are relatively easy to fix, but every once in a while you run across an issue that isn’t straightforward at all. Here are some suggested troubleshooting steps that can be employed when this happens.

Ensure that all features nested in another feature have been granted:

  1. Navigate to the feature (e.g. data form) that users are not able to access and view the XML.
  2. Look for other features referenced in the XML, such as search lists, data lists, and data forms and confirm that users have permissions for those features. You will need to look up features by GUID
    1. Copy the feature’s GUID from the XML, e.g.<FormField FieldID=”CAMPAIGNID” DataType=”Guid” Caption=”Campaign” CaptionResourceKey=”$$campaign”>
      <SearchList SearchListID=”e59a8d3a-94f9-4f0b-aeee-b880c1b368df” EnableQuickFind=”true” />
      </FormField>
    2. Navigate to the page of a feature of the same type.
    3. Replace the recordId in the page URL with the copied GUID. The recordID is the last GUID in the URL: https://atlasstaging.partners.org/CRM_STG/webui/webshellpage.aspx?databasename=MGH#pageType=p&pageId=36455595-2213-48df-9a19-11796b046c88&recordId=75eeaff6-1ee3-4d41-9266-58dd4781db81

If all features have been granted or if there are just too many features referenced in the XML, you can try a process of elimination:

  1. In a non-Production environment, create a test role, which can be deleted later.
  2. In the test role, grant all features that you suspect might be causing the issue. If you are unsure, start broad by granting all features in a logical security folder. For example, if users cannot access a revenue form, grant all features in the Revenue security folder.
  3. Assign the role to a user and see if the security issue is resolved. If not, clear those features from the test role and repeat steps 2-3 with a different block of features. Remember to log out between tests.
  4. If the issue is resolved, check the features that have been granted to see if  you can hone in on which feature might be addressing the issue and clear permissions for the other features. If you are unsure, clear a block of features that were granted by feature type, e.g. clear all view forms.
  5. Re-test and repeat step 4 until you’ve identified the feature.

Bear in mind that resolving these types of issues gets easier with experience as you become more familiar with how features work together.

Good to Know!

  • Permissions for a widget are granted via the underlying form or data list.  For instance, on the Fundraiser Portfolio Summary tab, the By Fundraising Plan Type widget permissions are associated with the Fundraiser Step Summary by Plan List datalist.

Leave a Reply