Form Access Configuration

The forms.ini file contains configuration information that the browser interface uses to provide automatic links to forms under certain circumstances. A sample forms.ini.sds file is provided with the UnForm installation for reference.

Starting at version 9.0.08, the system will merge other forms.*.ini files found in the UnForm directory at runtime, to facilitate easier management of more complex form configuration scenerios. In particular, UnForm Workflow utilizes this feature. The merge utilizes forms.ini as the initial file, then appends or adds sections found in other forms.*.ini files. The accumulated definition is stored in the file forms.ini.all, which serves as a cache and is rebuilt whenever any source files are modified or added. This speeds delivery of the forms configuration at runtime.

When a user is logged in and viewing document properties or a document image, a Forms tab is offered if any forms are configured that meet the session criteria, and links to all available forms are provided in that panel.

Sections in this file are identified by a [library|doctype] heading. When a document of that document type is viewed from that library, forms configured on the following lines will be available, depending on the user and user group membership. Any given form is only presented once, even if the circumstances would cause multiple configuration lines to present the same form.

In the above example, the user "theboss" can access the form_approval.html form, any user in the group "sales" can access the "form_rep_action.html" form, and any user can access the "form_site.html" form. All forms that meet the security criteria are available. For example, user "theboss" will have access to form_approval and form_site, and any user in the group "sales" will have access to form_rep_action and form_site.

In this example, "option" element is supplied to the web form rule set as cgi.option$="boss=1".

Library-oriented forms are available in the Browse interface when a library has been selected. Sections for these forms are identified with the header [library-name|*].

In addition to forms selected when viewing documents of a configured library and document type, forms can also be executed from search results and marked record lists. These are configured in a similar manner, with sections in the forms.ini file.

A [search] section denotes user or group form access when viewing search results. If the results of a saved search are being viewed, then a section named [search|saved search name] can be defined, also with user:userid and/or group:groupid access. Search-based rule sets can use a search object's doclist object to navigate and react to the search results.

Finally, a [marked] section can be defined to allow forms driven from a marked records list. The marked object can be used to navigate and manipulate the marked record list for a user's session.

In the above search example, the web form rule set will have cgi.option$="admin" or cgi.option$="nonadmin".

The forms.ini structure can be used to add custom panels to the main menu of the browser interface. Panels are added to the bottom of the menu, and link to web forms in the same window or a new window. A URL is constructed based on configuration entries, so that when the user clicks the panel, the custom web form is presented. The code of this form can perform whatever tasks are necessary, even to the point of loading a new page if desired.

Menu panel configuration requires multiple sections. First, a [menu] section must be defined that specifies form names and default titles for different users or groups. This configuration is almost identical to other web form sections, and the active forms are selected based on the session user. One exception to this format is that a ~value suffix can be added to the form name to allow multiple sections to be configured for a given form. The suffix is used only to locate a related configuration section, and is not considered part of the form's related HTML file name.

For each menu web form name, an additional section must be configured in the file to describe the attributes of that panel and how it launches the web form. The section header is [menu|formname], where formname is the name portion (including any ~value suffix) of the name,title assignment in the selection lines of [menu]. Within each section, the following name=value pairs can be used:

•	desc=description - provides panel descriptive text.

•	title=title - overrides the default title from the [menu] selection line

•	icon=file - names an icon file for the panel. Standard icons can be found in web/en-us/icons. A full path is not necessary if the file is in that or another standard UnForm directory, such as the install location and the web/en-us paths.

•	newwin=0\|1- if set to 1, the panel opens a new window for the form.

•	lb=library - names the library the form is associated with (this value is required).

•	doctype=doctype - names the document type the form is associated with.

•	All other name=value pairs are added to the URL that is used to run the form. Values can be retrieved from the form documents search property using JavaScript, or more conveniently, if the form loads the common.js script library, use the queryValue(name) function.

The following menu section describes the menu panels that will be presented to various users and groups. For example, the group AP will see two panels, My Docs Status Report and Capture to ERP Batch Processing, which will run the mdf7-v2 and mdf8-v2 forms, respectively.

A webform name of "break[,title]" displays a line break and title bar, rather than a menu panel.

The configuration for the mdf9-v2 form is shown below. The panel title will be the default, All Users Doc Status Report. The panel description and icon are shown. The web form will use library AP-MDF and will be shown in a new window. When the form is displayed, two additional URL fields will be available, Runtype=0 and Sortype=1, which code in mdf9-v2.html can reference.