2024 April Release

Advanced Use CasesPermanent link for this heading

You can create user-defined forms and process documents automatically.

FormsPermanent link for this heading

With the graphical form editor you can create new forms with drag-and-drop and extend objects with new properties without programming knowledge.

Either you can add a form to an existing object (shown in the properties of the object) or you can create basic objects based on a form.

Note: You can only create, edit and release forms and categories if you are authorized in the Edit Forms and Categories organizational policy. Explicit authorization is required as app.ducx expressions can be created in the context of forms and categories.

Form Fields

You can use the following form fields on your form:

  • Input Field
    A single-valued field of a particular type (e.g. string, date or object).
  • Item List
    A list of fields of a particular type (e.g. string, date or object)
  • Multiline Text
    A multi-valued field of type plain text, code or HTML.
  • Check Box
    One or more check boxes (multiple selection is possible).
  • Radio Buttons
    One value can be selected from several values with radio buttons.
  • Combo Box
    One value can be selected from several values in a drop-down box.
  • Standard Property
    Provides the ability to display standard properties of objects on the user-defined form.
  • Separator
    Used to structure related properties.
  • HTML Text
    Allows providing formatted descriptions on the form.

Types

You can define the following types for input fields and item lists:

  • String
  • Integer
  • Float
  • Date
  • Date and Time
  • Timespan
  • Numerator (only input fields)
  • Hyperlink
  • Password
  • Currency
  • Object
    You must also define the type of objects allowed (for example, standard objects).
  • Compound Type
    You must also select either a standard type or a type defined via a form. You can choose between standard and chart display.

Note: If the form has already been released, the type of a field can only be changed to compatible types (e.g. from string to hyperlink or password).

Additional Settings

Depending on the type, you can make further settings for form fields. In general, you can specify:

“General” tab

  • Label
  • Mandatory field
  • Description (is displayed with the field as an additional description to the label)
  • Help text (is displayed as context-sensitive help)
  • Initialization value

“Advanced” tab

  • Programming name
  • Readability or changeability depending on user rights
  • Mask (string and integer)
  • Expressions for computing and validating
    You are supported by syntax checking and auto-completion when entering an app.ducx expression. You can find more information in the white paper „Model-Base Customizing: new window“.

“Display” tab

  • Control (the used control, based on the field type, is displayed read-only)
  • Compute Control Styles
  • Compute Control Options
  • Display in New Row (if disabled, the field will be displayed next to the previous field)
  • Field Width (in percent in relation to the other fields in a row)

Trace output

When you use expressions for calculation or validation, it can sometimes be difficult to identify errors in the expressions. To simplify analysis, you can write trace output to the web browser console. To do this, you must go to the context menu of the Teamroom where the form is used, choose “Tools” > “Activate Trace Outputs” and allow trace output.

Call in expressions:

  • cooobj.Trace("string");
  • cooobj.Trace("string", value);

Output:

The output is a JSON data record.

  • c
    Context of the call (Teamroom).
  • d
    Current time.
  • s
    Section of the expression (if available).
  • t
    The text to be traced (first parameter of the trace call).
  • u
    Current user.
  • v
    The value to be traced (second parameter of the trace call).

Creating a FormPermanent link for this heading

Forms can be used in the context in which they are defined or referenced. To make forms generally available for Teamrooms (but not for app rooms), use a form and category collection in “Customizing”. Otherwise, forms can be stored in app configurations (“Forms and Categories” widget), in app rooms (“Templates and Presettings” action > “Forms and Categories” widget) or in Teamrooms (“Templates and Presettings” action > “Forms and Categories” widget).

To create a form, proceed as follows:

  1. Navigate in the “Forms and Categories” widget in the desired context.
  2. Click the “Create Form” action.
  3. Define the initial data of the form and click “Next”.
    • Enter a multilingual name.
    • Define a base form, if you want to take over tabs and fields of another form.
      Note: Template categories (component objects) can also be used as base forms. When template categories of installed software components change, the forms based on them are marked as “Changed After Release”. These forms must be re-released to apply the changes.
    • Define the incoming category for registration, if you want to register objects based on the form in a specific way.
      Note: When using the “Category for Generic Registration With Form”, only the user-defined form is displayed without default tabs during registration.
    • Define the base class to specify which objects the form is basically suitable for. If the form is used directly as a template, the template will have the corresponding object class.
      • Object With User Data
        Can be used for base objects, objects with object list and documents.
      • Document With User Data
        Can be used for documents.
        Note: If the form is used directly as a template, a content (“Content” tab) can be saved.
      • Container With User Data
        Can be used for objects with object list.
        Note: You can additionally specify whether it is a file. For the subordinate objects, the reference to the file is saved. This makes it possible, for example, that the properties of the file are also available as fields in Microsoft Word. In addition, file-typical actions such as “Replace”, “Close”, “Cancel”, “Restore” and “Scan” are automatically available.
      • Room With User Data
        Can be used for rooms.
        Note: If the form is used directly as a template, roles analogous to a Teamroom are available.
    • If you specify a symbol, it will be displayed instead of the object class symbol for objects that have the form assigned.
    • Abstract forms cannot be used directly but serve as base forms.
    • Check Suppress Template Creation, if you want to prevent that objects based on the form can be directly created. In this case, the form can only be assigned to existing objects (using the form category).
  4. Arrange the desired fields with drag-and-drop.
  5. Click “Next“.
  6. In the context menu of the form, click “Release for Usage”.

Note:

  • To use a form, on the one hand the users must be authorized in the corresponding room and on the other hand the form must be released for usage.
  • Changes can be released using the “Re-Release” context menu command.
  • You can withdraw the release with the “Withdraw Release” context menu command.
  • You can export a form as JSON file with the “Tools” > “Export Form” context menu command. You can import a form with the “Import Form” action or the “Tools” > “Export Form” context menu command.
  • An existing, currently not released category can be converted into a form (“Tools” > “Convert to Form” context menu command). Thus, no migration is necessary if the category is to be extended by user-defined fields.

Example

The following example shows in particular the possibility of using expressions in forms. The amount of each installment is to be calculated based on a total amount and a payment frequency.

Create a form (“Object With User Data” base class) with following three properties:

  • Total Amount (input field)
    Type: Currency
    Programming Name: totalpayment
  • Payment Frequency (radio buttons)
    Options: Monthly (ID: 1), Quarterly (ID: 2), Semi-Annual (ID: 3), Annual (ID: 4); The ID is determined by the order of the options.
    Programming Name: paymentfrequency
  • Installment (input field)
    Type: Currency
    Programming Name: installment

To calculate the installment dynamically, you must define expressions for the fields:

  • For the Total Amount and Payment Frequency field enable the Handle Changes of Values option and enter true as expression. This means that if you change the values, the installment value is updated directly.
  • For the Installment field enable the Compute Value of Field option and enter the following expression:

Calculating Value

Currency @installment = cooobj.totalpayment;

if (@installment.currvalue) {
  
// switch based on the ID of paymentfrequency
  switch (cooobj.paymentfrequency) {
  
case 1:
    @installment /= 12;

    
break;
  
case 2:
    @installment /= 4;

    
break;
  
case 3:
    @installment /= 2;

    
break;
  }

}

@installment;

Metadata of a FormPermanent link for this heading

You can also make the following settings in the properties of a form.

Advanced tab

  • Available Processing States
    You can define processing states that can be selected in the Processing State standard field.
  • Name Build Configuration
    You can specify a name build for the names of objects based on the form.
  • Prepare Commit Configuration
    You can define an app.ducx expression that is executed as part of the prepare commit.
  • Applicable for
    You can specify the object classes for which the form can be used.

Retention tab

You can specify whether objects based on the form are retention worthy. This tab displays the Category (Draft) retention properties. When the form is published, the settings are applied to the Category (Published).

“Translations” tab

For the languages ​​available in the Fabasoft Cloud, you can provide translations for the names and context-sensitive help. For each multilingual name of the form, you will find a corresponding entry.

Form TemplatePermanent link for this heading

In the form's properties on the “Form” tab, you will find the corresponding templates. You can use the templates to create objects directly based on the form. If you want to prevent this, choose Suppress Template Creation and publish the form again.

  • Generated Default Template
    If you do not define your own template, the default template is used to generate the template and published template, which are used when creating objects based on the form.
  • Template (Draft)
    You can define your own template (e.g. a Word document with default content), which is used when creating objects based on the form.
  • Template (Published)
    When releasing a form for usage the Template (Published) is generated from the Template (Draft).

Form CategoryPermanent link for this heading

In the form's properties on the “Form” tab, you will find the corresponding Category (Published).

The category can be used for the following use cases:

  • Adding a form to an object
  • Defining the registration behavior
  • Defining the applicability
  • Defining retention worthiness
  • Defining background tasks
  • Defining permissions

Note: The settings of the Category (Draft) are applied to the Category (Published) when the form is published.

Adding a Form to an Object

Not only basic objects that are based on a form can be created but it is also possible to extend existing objects with a form. This is particularly useful for templates.

To add a form to an object, proceed as follows:

  1. Navigate in the desired object.
  2. Click the “Properties” action.
  3. In the Category field (typically on the “General” tab), select the desired category. The category name corresponds to the form name.
  4. Click “Next”.

The form is displayed in the properties of the object. When you define the object as a template, the form is available with each newly created object that is based on the template.

Further Use Cases

A description of the further use cases of a form category can be found in chapter “Categories”.

Defining and Using a Compound TypePermanent link for this heading

Forms can also be used to define compound types, which in turn can be used in other forms as types for input fields or element lists.

Defining a Compound Type

To define a compound type, proceed as follows:

  1. Navigate in the desired Teamroom.
  2. Open the context menu in an empty part of the content area and click “New”.
  3. In the “All” category, select the “Form” entry.
  4. Define the initial data of the form and click “Next”.
    • Enter a multilingual name.
    • Define “Compound Type” as base class.
  5. Arrange the desired fields with drag-and-drop.
    Note: Compared to a standard form, the selectable fields and settings are reduced accordingly.
  6. Click “Next”.

Note:

  • The following additional settings can be made on the "Advanced" tab in the form properties:
    • Key for Unique Lists
      Defines the properties that are used as keys for unique aggregate lists.
    • Key for Sorting Lists
      Defines the properties that are used as keys for sorting aggregate lists.
    • Simple View of Properties
      Defines the properties that are displayed in the simple representation of an aggregate list (for example, in the property editor).
  • The form is now available as a draft. Publish the form for general use.

Using a Compound Type

To use the compound type, proceed as follows:

  1. Create a new form or open an existing form.
  2. Define an input field or an element list and select “Compound Type” as type.
  3. Select "Forms" as the type of content.
  4. In the Compound Type User Form field, select the previously defined type.
  5. In the Compound Type Display Mode field, select “Standard” or “Chart”. If you choose “Standard”, the field values of the aggregate are displayed. If you choose “Chart”, a Highchart diagram based on the aggregate data is displayed. However, the aggregate must have a certain structure according to the diagram type. The chart type (line chart by default) is defined on the “Display” tab in the Expression for Calculating the Control Options field.
    Example: dictionary({ chart: { type: "bar" } });
    For more information see:
    https://api.highcharts.com/highcharts/: new window
  6. Click "Next" twice to complete the editing.

CategoriesPermanent link for this heading

Categories can be assigned to objects (“General” tab) and thus influence the behavior of the objects.

Categories can be used for the following use cases:

  • Defining the registration behavior
  • Defining default follow-ups
  • Defining the applicability
  • Defining retention worthiness
  • Defining background tasks
  • Defining permissions

User-defined categories can be used in the context in which they are defined or referenced. To make categories generally available for Teamrooms (but not for app rooms), use a form and category collection in “Customizing”. Otherwise, categories can be stored in app configurations (“Forms and Categories” widget), in app rooms (“Templates and Presettings” action > “Forms and Categories” widget) or in Teamrooms (“Templates and Presettings” action > “Forms and Categories” widget).

The “Change Assignment” context menu command can be used to change the context of the category.

Note: You can only create, edit and release forms and categories if you are authorized in the Edit Forms and Categories organizational policy. Explicit authorization is required as app.ducx expressions can be created in the context of forms and categories.

Defining the Registration Behavior

By default, the “Register as” context menu command provides all possible registration targets. If the registration target is well-known, it can be restricted to improve the usability (Incoming Category for Registration field).

Defining Default Follow-Ups

To receive a reminder at a specific time, follow-ups can be used (Default Follow-Ups field). You can find more information on follow-ups in chapter “Follow-Ups”.

Defining the Applicability

Not every category make sense for every object class. Thus, the object classes for which the categories are allowed can be restricted (Applicable for field). In addition, if you want to use special base dates for follow-ups or retention periods a restriction to the object classes that provide the desired properties is needed.

If you want to restrict a BPMN process to a category and use activities that are allowed only for a certain object class, you can define the category accordingly (only the corresponding object class must be entered).

Defining Retention Worthiness

Compliance rules may enforce that objects must not be deleted for a defined time period (“Retention” tab).

In the properties of the category, on the “Retention” tab you can define whether objects with this category are retention worthy. In addition, define a Retention Period and a Base Date for the Beginning of the Retention Period. The calculation of the concrete retention period is carried out via a background task, which must be defined on the “Background Tasks” tab.
Note: Alternatively, you can also use the “Create/Edit Background Task” button on the “Retention” tab.

In the background task, select the “Determine Retention Period Based on the Category” action. In addition, determine the date when the background task should run. In general, it makes sense to use the Base Date for the Beginning of the Retention Period as Base Date for the time interval and, for example, “Immediately” as time interval.

For disposal, you can define another background task in the category. In general, it makes sense to define the Retention Period as base date for the execution of the task. As action, you can either select “Delete Automatically” or “Start Process”. If you want to start a process, you must also specify the process. In the process, a task with the activity “Retention Period Exceeded” should be defined.

When the background task is executed, the process is started and can be processed by the defined users in the worklist. The “Retention Period Exceeded” activity provides the steps “Delete”, “Extend Retention Period” and “Accept”.

Defining Background Tasks

Background tasks allow you to perform actions at a specific time (“Background Tasks” tab).

More information can be found in chapter “Background Tasks”.

Defining Permissions

In general, the defined team can access the Teamroom and its contents. Access to individual objects can also be granted via a category (“Permissions” tab).

Note: In order that the access rights granted via categories are evaluated, the entry “Extended by category” or “Extended by category and workflow” must be selected in the Access Protection field of the Teamroom.

Background TasksPermanent link for this heading

For categories, background tasks can be stored that execute an action at a definable point in time.

Actions

Possible actions (extendable by apps):

  • Determine Retention Period Based on the Category
  • Determine Retention Period Based on the Category and Close (File and Documents)
  • Execute Expression (App: Forms)
    Only available if the user is allowed to create user-defined forms.
  • Delete Automatically
  • Anonymize Object
    By default, the following data is removed (for special objects, such as support requests or tickets, additional fields are considered):
    • History
    • Remarks
    • References (referenced objects are deleted if the object is the origin, otherwise objects are removed)
    • Processes (the processes must be completed, otherwise the background task will fail)
    • Versions
  • Start Process (App: Workflow)

Note: The background tasks of objects are displayed on the “Background Tasks” tab. Whether background tasks that have already been processed are displayed depends on the action. You can override the default setting of the action using the Remove Processed Entries From the List of Background Tasks field.

Point in Time

The action can be executed at an explicit time or at a time based on a base date. Optionally, the execution date can be redefined if the base date is changed.

Repetition

It is also possible to repeat background tasks. The following cases can be distinguished.

Explicit date or date is not recalculated when the base date is changed

You can define a repetition rule that is applied starting with the execution time.

  • Unit
    Defines the unit of the interval (e.g. day or month).
  • Interval
    Defines the interval between the repetitions (number).
  • Repeat Until
    Defines the end time of the repetitions (infinite, explicit date, date value of a property).

Date is recalculated when the base date is changed

The background task is rescheduled after the selected action is executed and the base date is changed. Only Repeat Until can be defined as a repetition rule.

Suspend Background Task When Deleting

You can define whether the background task is automatically suspended when the affected object is deleted or canceled and again activated when the object is restored.

InboxPermanent link for this heading

In an inbox, rules for the processing of incoming objects can be defined. A rule consists of conditions and actions.

You can create an inbox in your personal folder (background context menu > “New” > “Inbox”). As for Teamrooms, you can also set a team for inboxes to define the access rights.

Note: You can only create and edit inbox rules if you are authorized in the Manage Inbox Rules organizational policy. Explicit authorization is required as app.ducx expressions can be created in the context of inbox rules.

To define rules for an inbox, proceed as follows:

  1. Navigate in the desired inbox.
  2. Click the “Manage Rules” action.
  3. Specify whether the rules are to be applied to top-level objects only. If so, the rules are applied to all objects (including folders) at the top level. Otherwise, the rules are applied to all objects (also in folder hierarchies), but not to the folders themselves, since in this case they are only used for structuring.
  4. Open the “Rule” menu and click “New”.
  5. Enter a name for the rule.
  6. Set the conditions for the rule. A condition checks whether the selected property contains the defined string (case-insensitive). Specify the string without wildcards. If you select the “Condition as Expression” entry, you can define an app.ducx expression as a condition. All conditions must be met for the rule to run. Do not specify a condition if the rule should always be executed.
  7. Specify the actions to be executed.
    • Execute User Defined Expression
      Allows defining an app.ducx expression that will be executed. In the app.ducx expression, you can use cooobj to access the object. You are supported by syntax checking and auto-completion.
    • Import Data (Asynchronous)
      The content of the incoming CSV file is imported. To do so, the target for the import and the type of import (e.g. members or organizational structure) must be specified. You can download templates for the CSV files via the respective manual actions (e.g. “Import Members” action of an organization).
    • Extract E-Mail Attachments (Asynchronous)
      The attachments are extracted from an e-mail and stored as separate objects for further processing in the inbox. The e-mail can be kept, moved or deleted.
    • Define Property Value
      A value is assigned to a property of the incoming object.
    • Assign Category
      The specified category is assigned to the incoming object.
    • Classify With Mindbreeze InSpire
      The incoming objects are classified. Based on the classification, a category is assigned to the object.
    • OCR Text Recognition (Asynchronous)
      For documents that can be converted to PDF, text recognition can be performed.
    • Start Process
      The specified process is started on the incoming object.
    • Assign (Asynchronous)
      The incoming document can be assigned based on QR code or PDF keywords. By default, the Fabasoft Cloud ID (e.g. COO. 1.506.4.4063) of the document whose content is to be replaced by the incoming document must be stored in the QR code or PDF keywords. The assignment is performed asynchronously at regular intervals.
      • Close Document
        Defines whether the status of the document is set to “Closed” by default. Closed documents can no longer be changed as long as the status is not removed.
        However, the type of assignment and closing can be influenced by an incoming category of the incoming document.
      • Continue Process on Object
        Defines whether an existing process is to be continued on the target object after assignment.
      • Continue Process on File of Object
        Defines whether an existing process is to be continued on the file of the target object after assignment.
      • Activities to Be Continued Automatically
        If a process is to be continued, it is also possible to define activities that are automatically continued. These activities automatically get the status “Not Executed”. If an activity to be automatically continued currently has the status “Startable” or “Started”, this activity is set to “Not Executed”. Other activities with the same activity definition will not be automatically continued in this case.
      • Start New Process on Object
        Defines whether a new process is to be started on the target object after assignment. For this purpose, you can specify the desired BPMN process.
      • Start New Process on File of Object
        Defines whether a new process is to be started on the file of the target object after assignment. For this purpose, you can specify the desired BPMN process.
      • Target for Unassignable Documents
        For non-assignable objects, you can define a folder as the target.
  8. Click “Next”.
  9. You can define additional rules, or complete the processing with "Save".

For an object placed in the inbox, the rules are checked according to the order. If all conditions of a rule apply to an incoming object or no condition has been defined, the defined actions are executed on the object. Only the first applicable rule is executed.

Note:

  • The organization of the placed objects must correspond to the organization of the inbox for the rules to be applied.
  • To be able to define the rules, you must be authorized in the Manage Inbox Rules organizational policy.

Classifying and RegisteringPermanent link for this heading

The Fabasoft Cloud in conjunction with Mindbreeze InSpire allows you to automatically classify documents and extract metadata. Especially when interacting with custom forms, you have a powerful concept for the incoming classification of documents for your particular application.

The following steps explain the basic operation:

  1. In a learning phase, Mindbreeze InSpire is trained to classify the documents. For the extraction of the metadata from documents, regular expressions can be defined.
  2. In productive mode, when classifying documents (either manually or automatically triggered), the metadata and classification are requested from the Mindbreeze InSpire service. Feedback can further improve the quality of the classification.
  3. For the classification value, a category with a corresponding import ID is searched and assigned to the document.
  4. The category can be used to start a specific registration or to initialize a process. If metadata can be retrieved from the document, the data will be prefilled and highlighted in color.

PrerequisitesPermanent link for this heading

The classification requires a Mindbreeze InSpire service, which can be configured by the organization administrator (for more information, see the administration help).

Using CategoriesPermanent link for this heading

The classification value calculated by Mindbreeze InSpire is used to determine a category based on the Import ID of the category. The following processing can be defined via the category:

  • type of registration
  • standard process
  • retention rules

Categories are used in the context of different apps and can be created or managed there (e.g. custom forms).

Using FormsPermanent link for this heading

User-defined forms (see chapter “Forms”) can be taken into account during classification. The corresponding Category (Published) is displayed in the properties of the form. Define in the properties of the category classification value as Import ID, which is returned by Mindbreeze InSpire for the corresponding type of documents. This way the registration is based on the form.

The metadata extracted during classifying is applied to the corresponding fields when registering.

Note: If the programming names of the user-defined fields do not match the Mindbreeze InSpire keys, your organization administrator must enter the corresponding mapping in the Mindbreeze InSpire service.

InboxPermanent link for this heading

Documents can be classified automatically via the inbox. To do so, you can define a rule that performs the “Classify With Mindbreeze InSpire” action (see also chapter “Inbox”).

WorkflowPermanent link for this heading

When using the “Register” activity, documents can be classified and registered via the workflow. You can start an ad-hoc process with the prescribed activity “Register”. In a predefined BPMN process, the activity can also be used (the usability has to be restricted to documents).

The following steps can be performed via the activity. Only appropriate work steps are offered in the respective context.

  • Open
    Opens the document.
  • Classify and register
    Classifies the document with Mindbreeze InSpire and opens the appropriate registration form.
  • Registering
    Opens the registration form.
  • Do not register
    Removes the activity from the worklist without performing a registration.

RegisterPermanent link for this heading

When you register a document, you can capture metadata of the document in a split view (on the left the metadata, on the right the document). If necessary, the document is also assigned (e.g. to a file).

Register (generic)

The generic registration is available if no category could be determined by the classification. In this case, you can capture metadata in a split view.

Register as (incoming category)

An incoming category determines the registration and assignment of the document. The incoming category can be assigned directly to a document or to a category that is assigned to a document. If no category is assigned to a document, the incoming categories of the licensed apps are also considered.

Register as (form)

When a form category is assigned to a document, the user-defined metadata can also be entered in a split view.

Form InboxPermanent link for this heading

The form inbox allows you to capture data using an HTML form and store it in the Fabasoft Cloud. You may also use an Inbox room as an alternative to a “Form Inbox”.

To create a form inbox and receive the identification of the form inbox, proceed as follows:

  1. Navigate in the desired Teamroom.
  2. Open the context menu of an empty part of the content area and click “New”.
  3. In the “Tools” category, select the “Form Inbox” entry.
  4. Enter a name and click “Next”.
  5. In the context menu of the form inbox, click “Properties”.
  6. On the “Form Inbox” tab in the ID field, you can find the unique ID of the form inbox. Copy the ID to use it further on in the HTML form.
  7. Click “Next”.

As an alternative to a “Form-Inbox” you can also create an “Inbox” room. In that case you have to use the Fabasoft Cloud ID as identifier for this Inbox room.

To define a corresponding HTML form on a page of your web site, proceed as follows:

  1. Create an HTML form on a page of your web site.
  2. Define the following attributes of the HTML form:
    • Attribute: action
      Value: https://at.cloud.fabasoft.com/foliop/createobject
      Note: Change the host in the URL to de.cloud.fabasoft.com if your form inbox is located in Germany or to ch.cloud.fabasoft.com in Switzerland.
    • Attribute: method
      Value: post
    • Attribute: accept-charset
      Value: UTF-8
    • Attribute: enctype
      Value: multipart/form-data
  3. Define a hidden field named objectclass and specify the Fabasoft Cloud ID or the full reference of the object class from which an instance is to be created in the form inbox when the HTML form is submitted. For example, you can use the following object classes:
    • Folder: COODESK@1.1:Folder
    • PDF Document: FSCACROBAT@1.1:PDFObject
    • Microsoft Word Document: COOMSOFFICE@1.1:WinWordObject
    • Microsoft Excel Worksheet: COOMSOFFICE@1.1:ExcelObject
    • Microsoft PowerPoint Presentation: COOMSOFFICE@1.1:PowerPointObject
    • Generic Content: GENCONT@1.1:ContentObject
    • Object with Form Data: FSCUSERFORMS@1.1001:ObjectWithUserForm or
      FSCUSERFORMS@1.1001:DocumentWithUserForm or
      FSCUSERFORMS@1.1001:ContainerWithUserForm
  4. As an alternative to the objectclass field, you can define a hidden field named objecttemplate, in which you store the Fabasoft Cloud ID of an object (e.g. a template) that is to be copied when the HTML form is submitted.
  5. Define another hidden field named inbox and set its value to the ID field of the form inbox (or the Fabasoft Cloud ID for an Inbox room).
  6. If necessary, define additional fields.

You can specify the following fields in the HTML form (unless otherwise specified, the fields are optional):

Field in HTML Form

Description

objectclass

Required field (as long as objecttemplate is not used): Defines the Fabasoft Cloud ID or full reference of the object class from which an instance is to be created in the form inbox after the HTML form is transferred.

objecttemplate

Only evaluated if objectclass does not exist. Defines the Fabasoft Cloud ID of an object that is to be copied after submitting the HTML form. The user "Form Poster Fabasoft Cloud" must have the right to read and copy this object (and dependent objects). Moreover the template must belong to the same cloud organization as the form inbox object. A template must be either a Document (ContentObject), an Object With Object List (CompoundObject) or a Basic Object (BasicObject).

inbox

Required field: Defines the ID of the form inbox. Alternatively, the Fabasoft Cloud ID of the form inbox can be used.

redirect

Required field: Defines the URL the submitter is redirected to after submitting the HTML form. The URL has to be defined absolutely including protocol and host. Protocol and host must match the URL of the page on which the form is embedded.

errorredirect

Defines the URL the submitter is redirected to in case of a processing error. If this parameter is omitted, the user will be redirected to the page defined by redirect. The URL has to be defined absolutely including protocol and host. Protocol and host must match the URL of the page on which the form is embedded.

The error code and an error description are provided in the errorcode and error parameters.

redirecttype

Defines how the redirect should be executed. Valid values are "302", "303", "307", all other values will be ignored. By default, the redirect is executed in the web browser by script or meta tag http-equiv="REFRESH". If this form field is set the redirect is initiated on the server by responding with the appropriate http status code and the URL in the http header "Location".

objname

Defines the name of the created object.

objsubject

Defines the subject of the created object.

objcategory

Defines the category of the created object.

If an objcategory is specified, fields that are assigned to the category can also be submitted as HTML fields. The Programming Name of the category fields must match the name of the respective HTML fields. The category must be usable for the created object (e.g. check property “Applicable for”). Categories created by a user form can only be used if they belong to the same cloud organization as the form inbox.

content

Allows uploading a file, which is then stored in the File field of the generated object.

This is only possible if the File property is assigned to the object class specified as objectclass. The relevant HTML field must be of type file. When saving, the system does not check whether the file extension of the uploaded file matches the data type of the object class. You can use the accept attribute in the input field to restrict the selection to specific file types. Only one file can be uploaded via this field.

attachmentkeys

Defines the names of the HTML fields (separated by a comma) for submitting additional files.

For the uploaded files, documents are instantiated in the Fabasoft Cloud, which are then stored in the property specified in the attachmentattrdef field of the instance of objectclass. The specified HTML fields must be of type file. If a value is specified in the attachmentkeys field, it is also necessary to provide a value for attachmentattrdef. The object class of the objects created for the uploaded files is determined by the file extension of the uploaded files. The file names are used as names for the created documents.

attachmentattrdef

Defines the Fabasoft Cloud ID or the full reference of the property, in which additional uploaded documents are stored.

If a value is specified in the field attachmentattrdef, you also have to provide the attachmentkeys. For object class Folder (COODESK@1.1: Folder), provide the COOSYSTEM@1.1:objchildren property.

<Reference/Fabasoft Cloud ID of other properties>

You may also set other properties that a user can change in the properties editor. These properties are identified by their full reference or their Fabasoft Cloud ID (e.g. COOSYSTEM@1.1:objexternalkey).

Note:

  • You can find the Fabasoft Cloud ID on the “General” tab in the Properties dialog of the corresponding object. To identify object classes and properties, you can use the full reference as well as the Fabasoft Cloud ID. You can determine the reference of properties by pressing the key combination Ctrl + Shift + # in the “Properties” dialog.
  • New objects will be created by the user “Form Poster Fabasoft Cloud”. This user will need change access to the Form-Inbox object or the Inbox room, respectively. When creating a Form-Inbox within a Teamroom access for this user is granted automatically. However, if you use an Inbox room you have to add this user explicitly to the team of this room. Just search for a user with e-mail-address “formposter@fabasoft.com”.
  • If a duplicate of an object is to be created (objecttemplate), the user "Form Poster Fabasoft Cloud" must also have the right to duplicate the object. If referenced objects are to be accessed (e.g. categories or text modules), the user must also have the necessary access rights for these objects.
  • If you assign a category (objcategory) to the new objects or if you have some rules configured in the Inbox room that assign categories or initiate a process, the user “Form Poster Fabasoft Cloud” will need also read access to the Teamrooms where you created the user form (and thus also the form category) or your processes.
  • If you pass a category (objcategory) with the form data but it is not set check whether the category can be applied to the created object.

Example

<!-- Replace "form inbox ID" with the value of the ID field of your form inbox and "redirect URL" by a URL of a page that schould be shown after the form was proccessed on the server.
  -->

<form action="https://at.cloud.fabasoft.com/foliop/createobject" method="post"
  accept-charset="UTF-8" enctype="multipart/form-data">

  <input name="encodingfix" type="hidden" value="&#9760;" />
  <input type="hidden" name="objectclass" value="COODESK@1.1:Folder" />
  <input type="hidden" name="redirect" value="redirect URL" />
  <input type="hidden" name="inbox" value="form inbox ID" />

  <input type="hidden" name="attachmentkeys" value="attachments">

  <input type="hidden" name="attachmentattrdef"

    value="COOSYSTEM@1.1:objchildren">

  <label for="objname">Name:</label>
  <input type="text" name="objname">

  <br>

  <label for="objsubject">Subject:</label>

  <input type="text" name="objsubject">

  <br>

  <label for="attachments">Attachments:</label>

  <input type="file" name="attachments" multiple="multiple" accept="pdf">

  <br>

  <input type="submit" value="Send">
  <input type="Reset">

</form>