Tuesday, February 14, 2017

Introducing organization-based permissions

With Form Builder, form authors can define permissions for the form they are creating. Permissions can depend on:
  • The user's role, for instance: "any user with the role admin can delete data".
  • The user being the one who initially created the data, also known as owner, for instance: "owners can view and update their own data".
  • The user being in the same group as the owner, e.g. users in the same group as the owner can read the data.
In addition to roles and groups, most companies have a hierarchical organizational structure, say:

Within such a structure:
  • An individual user can be a member of zero, one, or more organizations. For instance Mary could be a member of the "iOS" and "Support" organizations.
  • An individual user can have zero, one, or more organization roles. For instance, if Mary is also the manager of the "iOS" organization, in the system, she will have the role "manager" tied to organization "iOS". Informally, we could write this role as manager(organization = "iOS").
How does Orbeon Forms know about your organizations, what organizations each individual user is a member of, and what are their organization roles? In one of two ways, depending on where your users and organizations are defined:
With Orbeon Forms knowing about your hierarchy of organizations, users in those organizations, and roles like "manager" assigned to those users as necessary, form authors can define organization-based permissions. For instance, a form author can say that for their "expense report" form, managers can access data created by the people they manage. And this applies to people they manage directly, as well as people in sub-organizations. With that permission defined:
  1. Assuming Tom in the iOS organization creates an expense report,
  2. his manager, Mary will be able to access it,
  3. and so will John, the VP of engineering, defined in the system as manager of the "Engineering" organization,
  4. and so will Carla, the CEO, defined in the system as manager of Acme, which sits at the root of the organizational structure.

As illustrated by the case of the expense report, this feature allows forms to be used in a number of new scenarios. Organization-based permissions are also an important building block to the more comprehensive support for workflows that we are currently working on.

Support for organization-based permissions is available in Orbeon Forms 2016.3, and works on all supported databases, namely eXist, MySQL, PostgreSQL, Oracle, SQL Server, and DB2. Support on Oracle, SQL Server, and DB2 is available only on Orbeon Forms PE. And for more information, see the documentation on organization-based permissions.

Monday, February 6, 2017

Form Builder embedding

Orbeon Forms has had a Java embedding API since version 4.7. This allows you to embed a form within a Java web application, including from a JSP page.

Starting Orbeon Forms 2016.3,  in addition to published forms, you can also embed Form Builder in the same way: just use orbeon and builder as Form Runner application and form names.

The following features are supported:

  • Creating a new form definition.
  • Editing an existing form definition.
  • Testing the form definition.
  • Saving and publishing the form definition.

The embedding application can set the size the embedded Form Builder <div> element via CSS or JavaScript, and Form Builder will adjust its size accordingly. It is better to pick a fairly large minimal width and height as Form Builder just takes some space!

Note that the Form Builder "New" and "Summary" buttons are hidden when Form Builder is embedded, as navigating between pages is not yet supported when embedding.

For more, see the documentation. We hope you will like this new feature!