This is an Orbeon Forms PE feature.
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).
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.
Opening the Permissions dialog
This shows the following dialog:
Permissions dialog with no permissions enabled
After you click on the checkbox, you'll be able to set access restrictions on the Create, Read, Update, and Delete operations.
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 update it.
- Users with the role clerk can read any form data. They can also list data on the Summary page.
- Users with the role admin can do any operation, including deleting form data and listing data on the Summary page.
Permissions dialog with explict permissions enabled
- 1.On the Anyone line, set the operations allowed to all users.
- 4.On the following lines, you can enter a role name, and define what operations users with that role can perform.
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/List 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/List 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.)
[SINCE Orbeon Forms 2022.1]
The List permission allows specifying that the user can list form data on the Form Runner Summary page. If a user navigates to the Summary page of a form and the List permission is not granted to the user, the Summary page responds with an "Unauthorized" error.
With earlier versions of Orbeon Forms, the List permission was not checked separately. However, the ability to "Read" implied the ability to List on the Summary page.
The List permission implies the "Read" permission. Selecting List automatically selects the "Read" permission.
Forms created and edited with earlier versions of Orbeon Forms that have the "Read" permission enabled also implicitly have the List permission enabled, for backward compatibility. Opening such a form in Form Builder will show both the "Read" and List permissions. If the form author deselects the List permission, and then publishes the form, then the form will not allow the List permission, as expected.
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.
- [SINCE Orbeon Forms 2022.1] Access is also completely denied if the user doesn't have the List permission.
- 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.methodproperty was not taken into account. Since version 4.3, those permissions also apply if you are using header-driven roles.