View-Level Security

As part of your security policy, you can implement view-level security. With view-level security, if a user tries to load an Archibus view from a link inside an email or by typing the path and file name in the URL address bar of the browser, the view will not load if that particular user has not been granted access to that view.

The list of views that a user can access is controlled by the applications and processes that the Archibus Administrator assigns the user. In order to load, a view must be on one of those lists; that is to say, it must appear of the Navigator for the user.

Note : Constructing file names in JavaScript is incompatible with restricting loading of unassigned views, as the constructed file name will not be detected as a dependency of the JavaScript file. Instead, developers should include all possible variations of the file name somewhere in the JavaScript code and outside of comments.

Note : As a best practice, all security-conscious sites, particularly those that specify a "defense in depth" policy, should review Securing Web Central for Production Deployment to choose the right balance between security and flexibility for their deployment.

Home pages are generated as HTML files, and are not subject to view loading checks.

Enabling View-Level Security

To establish view-level security:

  1. Set the restrictLoadingOfUnassignedViews property to true in the \web-inf\config\security.properties file.
  2. Make sure that the Navigator has the complete list of views that users for each role need.
    • Verify that all view files that you use on your home pages are also on the Navigator. One way to do this is to check the process holding the desired view has a Process Type of Web PNav & Pages . This enables the process in the Navigator and makes it available for use in Home Pages.
    • Verify that all view files that users access from links inside notification emails are also on the Navigator.
    • Verify that these Navigator processes are assigned to the user roles for all users that must access them.
  3. You should also control access to features that create views. Archibus Security Groups can control access to the View Definition Wizard and the Views tab in the Smart Client.

  4. Additionally, you can configure data-level access (e.g. table and field level access per role), thus, even if a user loads an .axvw file, they will be able to view only the appropriate data within the form or report.

When assigning processes to roles, use role-process assignments. Do not use user-process assignments to assign processes directly, as view-level security disallows views that are assigned via user processes. This provision ensures that the list of user access rights remains manageable.

Application Support Views

The AbCommonResources-Application Support process holds views that need to be available to all users, and cannot be assigned to specific user roles.

This includes core views listed below, as well as some application views that support the Extensions for AutoCAD and Revit (specifically, those in \schema\ab-products\common\resources\view\overlay\ab-ov-rm.axvw , \ab-ov-eq.axvw , etc.).

"Core" view name Comment
navigator-details.axvw Default view for users with Navigator navigation
accessible-details.axvw Default view for accessible users
ab-my-user-profile.axvw My Profile view
ab-my-favorites.axvw My Favorites view

ab-my-jobs.axvw

ab-paginated-report-job.axvw

My Jobs view

ab-doc-checkin.axvw

ab-doc-checkin-new-version.axvw

ab-doc-checkout.axvw

ab-doc-lock.axvw

ab-doc-mark-deleted.axvw Views loaded into

Document dialogs
ab-data-transfer-main.axvw Data Transfer views
ab-select-fields.axvw Select Fields dialog

You can add custom views to the AbCommonResources-Application Support process.