Setting Permissions

Any object in the Process Director database may contain a list of permission rules that determine who can access the object and what functions they can perform against it. A permission rule only grants a user access. The absence of a permission rule granting a user access to an object will automatically deny access to it. If there are conflicting rules which either grant or deny a user access, the user will be granted access. When the server attempts to determine whether a user has access to an object in the database, it will search through the object's entire permission list until it finds a permission rule that grants the user the requested access, or until the end of the list. The system will apply the highest level of access that has been granted to that user in the list of permissions.

Different object types in the database have different permissions and options available to them. Objects that can be run (e.g. process definition, Form definition) will have more permissions options available to them, as will objects that can have children objects (e.g. folders, Form definitions, etc.).

The Permissions list is displayed in the lower portion of the permissions screen and will display the user and group names sorted alphabetically.

User Permission Types #

Permissions are granted to a user. A permission record gives permission to something for a specific object in the Process Director database. Different types of user permissions can be granted.

Object Permission Types #

Setting the permissions for a folder doesn't automatically set the permissions for the existing objects contained within it. You have the ability to replicate all permissions of the parent folder to all of the existing child objects in the folder. You have two options for doing so.

First, you can Replicate permissions to all child objects, which won't only overwrite the existing permissions on definition objects, it will also overwrite permissions on all of the form and process instances—including those instances that are active and in-progress.  This may completely change the ability of users to complete active Process Timeline or Form instances, so you should exercise caution in using this option in the production environment.

You also have the option, though, to replicate the permissions to child all child objects except for form, process, and Process Timeline instances. This is probably the preferred option for replicating folder permissions in the production environment where there are active processes running. Future process and form instances will be created under the new permissions regime, but existing instances will still run under the permissions regime that was valid when they were created.

Document Permission Types #

Process Permission Types #

Permissions are defined for a process definition, e.g., a Process Timeline. When the process definition is run, a child is created as an instantiation of the process definition. This “running” process is located beneath the process definition in the Content List. This instantiated, running process will inherit the Child Permission settings from the process definition.

Form Permission Types #

Permissions are defined for a Form definition. When a Form is filled out and submitted, a child object is created as an instantiation of the completed Form. This completed form is located beneath the Form definition in the Content List. Completed forms will inherit the Child Permissions from the Form definition.

Knowledge View Permission Types #

Knowledge Views display objects contained in the Process Director database. Authenticated and anonymous users can be given access to the objects displayed in a knowledge view. A user must have at least View permission to an object for it to be displayed in the Knowledge View.

Category Permission Types #

The category permissions are set in the category schema. To view the category schema use the Administration navigation button and select Meta Data Administration.

Default Permissions for New Objects #

Any time a new object (e.g. document, Review Set, sub-folder) is added to a folder it will be given the same permissions as the parent folder. If an object is added to the top-most folder (i.e. “<top>”) it will be given the same permissions specified in the default Folder Permissions hotlink. If an object is copied or moved to a folder, it will keep its original permissions.

Administrators #

Any user that is checked as the “System Administrator” is given full administrative privileges. A user that is a System Administrator has full permission (View, Modify, and Delete) to all objects in the Process Director database.

Adding/Removing Permissions #

Permission records can be modified for an object by selecting the Permissions button. Each permission record has to be removed or added individually. Existing permission records can't be modified, they must be removed and a new record added. To remove a permission record, click on the checkbox for that entry and select the Delete hotlink. To add a new permission record, select the type of user, the type of permission and click on the “Add New Permission” button. You can't delete a permission record that would eliminate Write permission for yourself; the system will return an error message. If this occurs, add a new permission record granting your User ID Write permission, then delete the other permission record.

Documentation Example #