Making authentication easier with a new built-in user menu, login and logout pages

In cases you need users accessing Orbeon Forms to be authenticated, if you decide to have that authentication done by your web container, the latter needs to be configured with:

• A login page, where users enter their username and password, which is then checked by the web container before it lets users through to Orbeon Forms.
• A logout page, which, as you might expect, logs users out by invalidating their web container session, and tells users they have been successfully logged out.

You can create your own login and logout pages, but since version 2018.2, you can also use the built-in login and logout pages provided by Orbeon Forms, making the authentication setup with Orbeon Forms simpler.

Also since version 2018.2, Orbeon Forms provides a user menu you can show in the navigation bar, allowing users to login, logout, and register. The user menu is configurable:

• You can decide whether you want the menu to show.
• You can decide what entries are shown by the menu. For instance, you might want to have Login and Logout, but not Register.
• For each menu entry, you can configure where users are taken when they select that entry. Out-of-the-box Login and Logout entries take users to the built-in pages discussed earlier, but you can configure the menu to take users to other pages should you already have your own login/logout pages.

For more on this, see Login & Logout.

Paging large repeated sections

Orbeon Forms 2018.2 introduced synchronized master-detail views. This is a powerful feature which helps form author and end-users alike deal with large forms. So far, however, all the repetitions of the details were presented on a single wizard page. If there is a lot of information to capture in each detail or a lot of items to repeat, the resulting page can still become very large.

Orbeon Forms 2019.1 introduces an improvement to this feature: it allows each individual detail to show on a separate wizard page. This makes it easier for the user as there is less information presented on each wizard page. In addition, you can configure a custom repetition label for use by the wizard's table of contents.

In the example below, you can see that the wizard's table of contents reflects the list of travelers. It does so automatically and updates as you add, remove, move, or update items in the master view.

Master View with Synchronized Table of Contents

You configure the repetition label direction in Form Builder, with a new "Repetition Label" section setting. The label can be dynamic and make use of fields within the given iteration. Here we include the traveler's name in the label.

Custom Repetition Label

As a user, you navigate to each detail separately. Here, you can start with Alice, but you can as well start with Bob since every detail is independent from the other.

Traveler Detail

When using strict validated navigation, all the details need to be filled before the user can navigate to the next section, here "Confirmation".

For more details, see the documentation:

• Paging large repeated sections (wizard)
• Paging large repeated sections (synchronization)
• Dynamic iteration label

We hope you will like this Orbeon Forms 2019.1 feature!

Back and forward navigation

Handling browser back and forward navigation has historically been difficult for web applications. [1] What should they do when the user activates the back and forward buttons?

With plain old static web pages, the answer is easy: just show the page which is back or forward in the browser’s navigation history, and that’s it. The browser will do the work for you, in fact, and retrieve the content from cache or again from the server.

But with pages that have some dynamic behavior, or even more so with full-fledged web applications, the answer is more complicated.

One philosophy which is consistent with what happens with static web pages consists in showing the app as it was when you left it. [2] Certainly, you don’t want to see a page or form which is completely out of date and missing the data you just captured, for example. And unfortunately, that latter behavior is still the default with most web browsers.

To be fair, web browsers have started making things easier to web applications when the circumstances are right, under the name “bfcache” (for “back/forward cache”). Firefox and Safari have had this feature for a while, and soon Chrome will have it too. This is great for users and works in many cases, but there are still situations where the browser won’t be able to restore the application (for example if the state has been removed from cache to save memory).

Until that kind of feature is available perfectly everywhere, your application has to do some work to behave as the user would expect it. Specifically, the web application must realize that the user just landed on it with back or forward navigation, and restore its content as needed. In the case of Orbeon Forms, this means making a call to the server to retrieve some state that allow the form to update itself. And Orbeon Forms has done this work since the very beginning, even before browsers had APIs to help with that. [3]

Now, with Orbeon Forms 2019.1, we have made improvements to the reliability of this feature by using the web browser's history API. Orbeon Forms stores some small state associated with the page, and upon back/forward, performs that call to the server to restore everything as it was before navigating away. This is made possible since Orbeon Forms’s UI software is based on computing differences to apply to the user interface when changes happen, such as changing field values, adding repetitions to a grid, and or hiding a section.

The bottom line is that with Orbeon Forms, you can expect that if you use the back and forward buttons, the data you just entered is not lost. And we have just made that more reliable.

---

1. In fact, many modern web apps still don’t handle browser navigation in a reasonable way, and that’s if they care at all to address the question.  ↩

2. Possibly with some refresh of data for applications where it makes sense.  ↩

3. Orbeon Forms used hidden form fields for that purpose until version 2018.2.  ↩

Freezing rows in repeated grids or sections

Repeated grids and sections in Orbeon Forms are already quite flexible. With Orbeon Forms 2018.2, we added a new option to allow making a number of repetitions frozen.

Repeated grids and sections usually work as follows:

• At design time, the form author:
• creates a repeated grid or section and adds controls within it.
• specifies a minimum and/or a maximum number of allowed repetitions (there might be no minimum or maximum).
• specifies a number of initial repetitions.
• At runtime:
• Users can add, remove, or reorganize the repetitions.
• Optionally, the grids can be populated by services.

In some cases, some repetitions must not be allowed to be removed or reorganized. This is what this new feature is about: freezing the first N iterations of a repeated grid or section.

You enable this simply by selecting the "One repetition" or "Other" radio buttons in the "Repeated Content" tab of the "Section/Grid Settings" dialog.

Repeated Content Settings

The number of frozen iterations must be at most the minimal number of iterations. If that's not the case, the number of frozen iterations will be set to the minimal number of iterations.

At runtime, the user can still enter information in the frozen rows, unless form controls are specifically marked as readonly. But the repetitions cannot be moved or removed.

Repeated grid with two frozen repetitions

In the example above, the user cannot insert a new repetition between the first two repetitions. The menu for the first frozen repetition is not even shown.

For more, see the documentation. We hope you will enjoy this Orbeon Forms 2018.2 feature.

Orbeon Forms 2018.2.3 PE

Today we released Orbeon Forms 2018.2.3 PE. This update contains bug-fixes and is recommended for all Orbeon Forms 2018.2 PE, Orbeon Forms 2018.2.1 PE and Orbeon Forms 2018.2.2 users.

This release addresses the following 40 issues since Orbeon Forms 2018.2.2 PE:

Security

• Remove YUI menu component for CVE-2010-4710 (#3972)
• Possible jackson-databind vulnerabilities (#4006)

Form Builder:

• JavaScript error in Form Builder when opening section (#4011)
• XBL component with `fb:template` causes exception when opening Form Settings dialog (#4027)
• In Form Settings, support components that don't create/remove attributes with listeners (#4030)
• Failing to add iteration to top-level repeated section containing a section (#4032)
• Inserting iteration before causes "illegal state when comparing controls" (#4035)
• NPE when opening Form Settings if inspector is enabled (#4055)

Form Runner:

• Form controls
• Dates with `+01:00` are not recognized (#4005)
• Support users typing dates without separators (#4021)
• fr:datetime fails to parse date in some cases (#4029)
• `fr:time` to support placeholder (#4037)
• Show `not-allowed` cursor when over date picker for read-only date (#4020)
• Form Builder control settings: support specifying "no grouping separator" (#4024)
• fr:number: incorrect formatting with pseudo-decimal point (#4026)
• Embedding and Liferay support
• Liferay 7: Liferay language selector portlet fails when in review mode (#3978)
• Issue loading class `HttpRequestInterceptor` with Liferay 7.0 Enterprise sp8 (#4009)
• Call `Liferay.Session.extend()` function upon Ajax calls (#4023)
• Proxy portlet and embedding JARs cause class loading error (#4001)
• Support Liferay 7.1 (#3959)
• Liferay proxy portlet randomly "swallowing" POST requests? (#3647)
• Other fixes
• Section titles must support HTML (#3671)
• Newly-relevant controls after repeat fail to update (#3976)
• Option to disable background on calculated fields with labels (#4004)
• New button has no effect (#3970)
• `fr:open-select1` not showing properly when printed in automatic PDF (#3979)
• Error when uploading files during auto-save with form with multiple attachment files (#4012)
• JavaScript error on iOS with date field in wizard (#4015)
• Initially collapsed and hidden section partially shows when it becomes visible (#4016)
• Autosave during upload can cause an error (#4003)
• fr:error-summary doesn't show error with section id ending with `-control` (#4022)
• Additional slash in TinyMCE theme URL leads to 404 on WebSphere (#4017)
• `type` element always missing on `xs:element` in generated schema (#4014)
• Schema generator option to produce type for maybe non-relevant elements (#4039)
• fr:synchronize-repeated-content: make `apply-defaults` configurable (#4038)
• Can't add a repetition to repeated section after the last one has been removed (#4018)
• Issue deploying on WildFly (#4045)
• "New from service" doesn't set data if there is no migration metadata (#4048)
• "Boolean Input" checkbox doesn't show in PDF (#4044)
• Help doesn't always show correctly in repeated grid (#4062)

You can download the latest version of Orbeon Forms from the downloads page.

Don’t forget to grab a trial license for the PE version.

Please send feedback:

• via Twitter
• to the discussion list
• or as comments on this blog post

We hope you enjoy this release!

Summary page versioning support

Orbeon Forms supports versioning of form definitions. However, the behavior of the Summary page did not properly reflect that in a useful fashion.

Since Orbeon Forms 2018.2, when more than one form version is available, the Summary page now offers the user the choice of the version to access. This is important because different versions can behave like very different forms. This means that the search fields and the columns containing data can vary between form definitions.

Summary Page for version 1 of the form

Summary Page for version 2 of the form

When you change the form version using the dropdown selector, the Summary page automatically reloads the appropriate data from the database and updates the grids and search fields.

When navigating from the detail page to the Summary page, the appropriate version is also automatically loaded.

We hope you will like this Orbeon Forms 2018.2 feature. For more, see the documentation.

Field-level encryption

In Orbeon Forms 2018.2.2 PE, we introduced the ability for you, as a form author, to mark form fields as encrypted at rest, by simply checking a checkbox in Form Builder. When doing so, with no additional effort, the values of those fields will, at all times, be encrypted in your database.

Checkbox to mark field for encryption

You might want to encrypt the values of fields you deem sensitive, for instance to prevent access to those values even to a person who has access to your database, such as a database administrator, or a hacker in case your database server has been compromised. This feature can help you comply with data protection and privacy regulations, such as GDPR.

For more detailed information about this feature, see the page Field-level encryption in the Orbeon Forms documentation.