# Deployed forms

## Availability

This is an Orbeon Forms PE feature.

## Introduction

You can restrict which users can access which forms, and what operations they can perform. Those restrictions apply to the forms you create once they are deployed, not to editing those forms in Form Builder (for the latter, see [Access control for editing forms](https://doc.orbeon.com/~/revisions/-LFrzxlvP9UXA6_RDYI9/form-runner/access-control-and-permissions/editing-forms)).

## Enabling permissions

By default, no restriction is imposed on *who* can do *what* with forms you create in Form Builder. You enable permissions by going to the Form Builder toolbox, and under *Advanced*, clicking on *Permissions*.

![](https://4129616727-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LEkBiSDvlXs3VWiO0Zu%2F-LFZt2gpdgtXSCCHe0-f%2F-LEkBvjyJnZXF5GahqjH%2Fadvanced-menu.png?generation=1529627341696626\&alt=media)

This shows the following dialog:

![](https://4129616727-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LEkBiSDvlXs3VWiO0Zu%2F-LEkBmMpnaxnftLGDglW%2F-LEkC1zxziclsooZAW1F%2Fpermissions-enable.png?generation=1528743343648358\&alt=media)

After you click on the checkbox, you'll be able to set access restrictions on the *create*, *read, update*, and *delete* operations.

## Setting permissions

### An example

In the example below:

* Any user (even anonymous) can fill out new form data.
* A logged-in user who created form data can later read and update it.
* A logged-in user member of the group of the user who created form data can read it but not updated it.
* Users with the role *clerk* can read any form data.
* Users with the role *admin* can do any operation, including deleting form data.

![The Permissions dialog](https://4129616727-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LEkBiSDvlXs3VWiO0Zu%2F-LEkBmMpnaxnftLGDglW%2F-LEkC1zz5znDhljB9kag%2Fpermissions-dialog.png?generation=1528743343677882\&alt=media)

### Role types

1. On the *Anyone* line, set the operations allowed to all users.
2. On the *Owner* line, set the operations allowed to the user who created the data. See also [Owner and Group Member Permissions](https://doc.orbeon.com/~/revisions/-LFrzxlvP9UXA6_RDYI9/form-runner/access-control-and-permissions/owner-and-group-member). \[SINCE Orbeon Forms 4.3]
3. On the *Group members* line, set the operations allowed to users in the same group as the owner. See also [Owner and Group Member Permissions](https://doc.orbeon.com/~/revisions/-LFrzxlvP9UXA6_RDYI9/form-runner/access-control-and-permissions/owner-and-group-member). \[SINCE Orbeon Forms 4.3]
4. On the following lines, you can enter a role name, and define what operations users with that role can perform.

### Permissions in detail

Permissions you set in the dialog are *additive* – Say you defined permissions for two roles, where users with the *reader* role can read and users in the *clerk* role can delete, users with both roles ( *reader* and *clerk*) are allowed to perform both operations (reading and deleting).

Operation on *Anyone* apply to all other rows – When you select a checkbox for a given operation on the first *Anyone* row, that checkbox will be automatically checked and disabled so you can't change it, for any additional row, since you wouldn't want to authorize users with additional roles to perform less operations.

*Update* implies *read* – On any row, if you check *update*, then *read* will be automatically checked, as it wouldn't make sense to say that some users can update data, but can't read it, as when updating data, obviously, they must be shown the data they are updating.

*Create* can't be set for the *owner* and *group members* – The owner/group is a piece of information attached to existing form data, keeping track of the user who create the data, and the group in which this user is. This information is only known for existing data, so assigning the *create* permission to the *owner* or *group members* doesn't make sense, and the dialog doesn't show that checkbox.

Permissions for the *owner* and *group members* can be set independently– If you want data to be accessible only by people who created it, check read/update/delete for the owner but not for group members. If you want data to be accessible by all people in the same group,check read/update/delete for the group members and don't check them for the owner if you want the owner to lose access to that data in case the owner changes group. (The latter highlights the need for permissions owner and group member to be set independently.)

## How permissions affect Form Runner pages

Which operations the current user can perform drives what page they can access, and on some pages which buttons are shown:

* On the Form Runner *home* page, all the forms on which the current user can perform at least one operation are displayed. Then, for each one of those forms:
  * If they can perform the *create* operation on the form, a link to the *new* page is shown.
  * If they can perform any of the *read*, *update*, or *delete* operation on the form, a link to the *summary* page for that form is shown.
* For the *summary* page:
  * Access is completely denied if the current user can't perform any of the *read*, *update*, or *delete* operations.
  * The *delete* button is disabled if the current user can't perform the *delete* operation.
  * The *review* and *pdf* button are disabled if the current user can't perform the *read* operation.
  * Clicking in a row of the table will open the form in *edit* mode if the current user can perform the *update* operation, in *view* mode if they can perform the *read* operation, and do nothing otherwise.
* For the *view* page, access is denied if the current user can't perform the *read* operation.
* For the *new* page, access is denied if the current user can't perform the *create* operation.
* For the *edit* page, access is denied if the current user can't perform the *update* operation.

\[SINCE 4.3] In Orbeon Forms 4.2 and earlier, role-based permissions set in Form Builder could only be driven by container-based roles and the value of the `oxf.fr.authentication.method` property was not taken into account. Since version 4.3, those permissions also apply if you are using header-driven roles.

## See also

* [Owner and group member permissions](https://doc.orbeon.com/~/revisions/-LFrzxlvP9UXA6_RDYI9/form-runner/access-control-and-permissions/owner-and-group-member)