| Table of Contents | ||||
|---|---|---|---|---|
|
| Info | ||
|---|---|---|
| ||
Restrict what a user can view in a database
To limit what users can see in an active database, choose the restrictions iconnext to the defined period (if a restriction is active, the icon will be black) to open a restrictions form.
In the image below, the first two databases in the example are accessible, but have restrictions. The third one is accessible and the fourth is not accessible (and is outlined in red).
Default restrictions
Normally, restrictions are applied on a user-by-user basis, i.e. if a user doesn't have a restriction, it implies that they have access to all data in a database. Database restrictions allow that logic to be reversed, so that any user without a specific restriction will get the default one from the database. Instead of applying a user restriction to limit access, it is used to increase access. This allows a 'secure by default' way of setting up the database.
Example: Create a default restriction on streams. In the example below, a default restriction has been created to allow access only to the principle stream, which is 'Sales'. All users without a specific restriction would only be able to access the 'Sales' stream. To grant a user access to the 'Budget' stream, you would add a user restriction.
You could set a default restriction on measures to allow access only to the 'Value' and 'Quantity' measures. This would mean that all users would be prevented from seeing profit and margin figures, unless specifically granted that access. For example, you would grant access to the profit/cost of sales measures for managers and directors only (see User restrictions).
Default restrictions based on user settings
A further refinement to the regular way of applying database restrictions is to base a dimension restriction on a user's settings, instead of an absolute, fixed value. The example above discusses why having an entity restriction such as 'Rep Code = XXXX' wouldn't generally be useful. By replacing the fixed value with one of the two user variables {{user:group}} or {{user:territory}}, the appropriate setting value from the user will be applied when they login. This allows the restriction to be created at a database level, but applied per user. In the screens below, a default restriction has been set on the database using the territory value from the user. In the second screen, the users have multiple territory (or State) codes assigned to them, which are used when they access the database. Note: Semi-colon separated values are used when specifying multiple allowed values.
Significantly for this type of restriction, a mistake or a missing territory or group value value on the user will result in no data being exposed. This mechanism provides a 'secure by default' way of setting up the system.
Use sub-databases to restrict data view
If sub-databases have been created for the site, you will see a 'Sub-databases' option appear when setting restrictions on a database, as shown below. As the name suggests, these contain only a sub-set of data. Creation of these sub-databases, or so-called 'splits', are an advanced form of user security which needs to be implemented by a Phocas consultant.
Sub-database names
The names will always begin with the master database name that they relate to, followed by an underscore, followed by another other name to make them unique. For example, a master database of Phocas_Sales could have sub-databases called Phocas_Sales_Depot001, Phocas_Sales_Depot002, etc.
Impact on sharing
Because these sub-databases are available to different groups of users as subsets of the same application database (and in fact appear as the actual application databases), favorites and dashboards can be shared across databases and between users.
Remove a user's access to a database
Clear the user/database cell to deny the user access to a database. The database will appear with a blank field and red outline to indicate no access.
This page outlines how to manage access and restrictions for a database, for one or more users, via the database screen. For other methods and more information, see the Overview of access to data page.
This action overrides any default database restrictions that might have been applied to the database.
Click Administration > Databases, then click the database name (blue link) to open the database settings screen for that database.
Click the Users tab.
Review the current access and restrictions:
If a period displays next to a user’s name, it means the user has access to the database. If no period displays (a red outline displays on the period box), it means the user does not have access to that database.
If the lock icon (Restrictions button) next to the period is grey, it means no restrictions have been applied to the database. If a black button displays, it means one or more restrictions have been applied.
Locate the user you want to update.
Manage the access and restrictions as required:
Give access to the database: Select a period from the list of defined periods that have been set up for the database. This action grants the user access to the database and the period you select becomes the default period that is applied when the user opens the database. Learn more about periods, a core concept in Phocas.
Remove access to the database: Select the blank option from the dropdown list.
Add or update restrictions: Click the Restrictions button (lock icon) next to the period dropdown list, then configure the restrictions and click Save. See the examples on the Manage default database restrictions page, as the process is similar.
Repeat the above steps 4 and 5 to manage the access and restrictions for other users.
Click Save, then click Close.