Relate and Security

Relate inherits its permission capabilities from the BlueStep platform.  Namely, groups or individuals can be granted various permission levels, or roles, to different pieces of data throughout the system.  However, Relate is also unique in many ways with regard to permissions.  Below are some of the highlights:

• Different types of Relate configuration data have different roles.  Record types and categories have only two roles.  Forms and fields have 4 roles.  Other Relate items have standard roles.  The way that these roles differ from standard roles is complex, but you can get the highlights by reading the legend at the bottom of each type of permission screen.
• The "creator privilege" normally grants whoever first created a piece of data permanent editor permission, but with most Relate items this is not the case.  By default the creator of Relate data (form entries) has no greater access than anyone else with the same account settings.  However, when configuring Relate forms and fields there is a special security group, Relate Creator, which can be used to grant special access to the creator of an entry.  By granting permission to the Relate Creator group, the original creator of a form entry may be given access to view or edit data that other users cannot.
• Relate configuration elements are not the actual data being protected by security.  The Relate records with their various form entries are primarily what is being protected.  However, there is no way to set permissions on an individual record or on a form entry.  So how do permission work?  When talking about permissions and Relate configuration elements it is useful to think of the Relate elements as windows or filters to the underlying data.  The window on a house have blinds can be opened or closed to reveal the view on the other side.  Relate permission work similarly:  Permission to the Relate element grants the ability to create, view or modify the form entry data via that element.  In many instances Relate elements are chained together or nested within each other.  In such cases the end user must have permission to see through all of the layers of configuration, or all of the windows, in order to view the data at the end of the chain.
• Relate has a special security group "Relate Self" which is used primarily to allow a user access to the data associated with their own account.

Security and Relate

Access to Relate is controlled by security, but Relate also defines and controls many aspects of security and authentication.  A user account in the BlueStep system is actually a Relate record.  The "Individual" record type, the "User" category and the "Online Profile" form define a user account.  Since a user account is a Relate record additional categories and forms can be added to the account and viewed and edited in the "My Account" area of the BlueStep platform.

Also, any data attached to an account can be used to control security group membership using special dynamic security groups.  With dynamic security groups, any information associated with a user account via Relate can be used to define security group membership rules.  These security group rules may be as simple as "if the box is checked, you're in the group" or more complex, bordering-on-insanity rules like "You must have an active RN credential recorded and have logged least 35 hours on your time card in one of the last two pay periods."  You can guess what side of the border such a rule is on.

Exercise 1: Permission Levels

Get access to a non-administrative account.  You may want to create a test account for this purpose.  On each type of relate element, assign different permission levels to your test user.  Use the "Temporary Login" feature found on the "Tools" menu to quickly switch between your test account and administrative account.  Optionally you may want to login using two different sessions (use two different browsers such as Internet Explorer and Firefox OR access BlueStep using two different domains of the same organization.)  Test each permission level to see how it effects what the test account sees.

Exercise 2: Dynamic Groups

Use the same test account as in exercise 1.  Figure out how an existing dynamic security group is configured, or create your own dynamic security group.  See if you can make your test user a member of the group and remove them from the group.  You can see what security groups a user account is a member of using the "User Lookup" tool found in organization administration site and unit administration sites.  Grant access for your dynamic security group to various Relate elements and check out the change from the test user's perspective.  For an advanced excercise, try out the unit security settings on the security group.  Move a Relate record from unit to unit and change the unit security settings while observing the effect on the test user's access level.  For extra credit you may want to try making the user part of multple groups and explore the complex interactions that are possible with multiple groups, and multiple relate elements, each with differing permissions, displayed together on a page.

Exercise 3: Special Security Groups

Try using the "Relate Self" and "Relate Creator" security groups.  You will need multiple test accounts to test the Relate Creator group.  See how Relate Self security effects anonomous users during account sign-up.