Specific Form Builder permissions are configured with
If you'd like to have multiple classes of Form Builder users where some case edit, say, form in the
hr app, while other can edit forms in the
sales app, then you'll want to setup the
NOTE: The file used to be called
In this file you map role names to applications and forms. For instance, the following tells Orbeon Forms that only users with the role
hr-form-editor can edit or create forms in the
hr app, and only users with the role
sales-form-editor can edit or create forms in the
sales app. As you can infer from the syntax, you could be even more specific and only give access to users with a given role to a specific form in a specific app.
<roles><role name="hr-form-editor" app="hr" form="*"/><role name="sales-form-editor" app="sales" form="*"/></roles>
<role> element refers to as single role name. It is not possible to place multiple space-separated roles in the
Orbeon Forms can infer the roles for the current user either based on information it gets from the container or from an HTTP header. Those two cases are detailed in the following two sections. Once you've defined your
form-builder-permissions.xml and done the appropriate setup for container-driven or header-driven roles, as described below:
The Form Builder summary page will only show the forms users have access to.
When they create a new form, if users don't have the right to create a form in any app, instead of seeing a text field where they can enter the application name, they will see a drop-down listing the possible application, as shown in the following screenshot:
LIMITATION: Restrictions on the form name in
form-builder-permissions.xml are at this point not supported; only restrictions on the app name are supported. This means that you should always use
form="*". If you define a restriction on the form name, it won't be enforced at the time the form is created, allowing users to create, save, and publish a form with an undesirable name. However they then won't be able to see the form they created when going back to the summary page.
[SINCE Orbeon Forms 4.3]
form-builder-permissions.xml also impacts the Form Runner Home page, which supports unpublishing and publishing forms.
If the configuration is unchanged, by default users cannot unpublish/publish from the Home page. In order to allow this feature, you must configure at least one
In general, the behavior is as follows:
by default no
<role> elements are present
for the Form Builder Summary and New pages, this is equivalent to:
<role name="*" app="*" form="*">
for the Form Runner Home page
user cannot unpublish/publish any forms
user cannot see unavailable forms
<role name="*" app="*" form="*">:
user can unpublish/publish any forms
user sees unavailable forms
This logic ensures:
that Form Builder is usable out of the box even without setting Form Builder permissions
that the Form Runner Home page, which can by default be accessed by any user unless it is explicitly protected, does not inadvertently provide access to administrative functions
The paths used by Form Builder look as follows:
Create a new form
Edit a form with the given id
View all the editable forms
Path-based access restrictions can also be implemented to fully or partially protect Form Builder access.
Orbeon Forms does not specifically provide a mechanism to protect access based on paths, but your container or web server might.
Setup users for access control - How to setup Orbeon Forms so that users and roles are provided.
Login & Logout - Optional user menu for providing links to login and logout functions.
Access control for deployed forms - How to control access to deployed forms.
Form fields - How to control access to specific form fields based on the user user's roles.