...

If this attribute is missing, "hidden": false is used as a default.

permissions

This optional attribute defines who By default any logged-in user can see the form inside an app. If this attribute is missing, all users can see this form. Example:

{
  ...
  "permissions": {
    "read": ["ROLE_DEVELOPER"]
  }
}

The attribute read defines a list of permission strings the currently logged-in user must match at least one of. By default such a permission string is the name of a required role. In this example, the user must be assigned to ROLE_DEVELOPER in order to see this form inside the app.

PIPEFORCE URIs as permissions

Furthermore, also PIPEFORCE URI prefixes are supported to define permissions such as:

• $uri:user:<username> = Logged-in user must have this username.

• $uri:group:<groupname> = Logged-in user must be member of group with name <groupname>.

• $uri:role:<rolename> = Logged-in user must have assigned this role (this is used by default also if no such prefix is used.)

Example:

{
  ...
  "permissions": {
    "read": ["$uri:group:supervisors"]
  }
}

schema

The schema attribute defines a PIPEFORCE URI which is called in order to retrieve the Form schema for this form.

For example, the attribute could look like this:

"schema": "$uri:property:global/app/tld.domain.myapp/object/person/v1/schema"

Which could return a JSON schema like thisthe the form using role based access rules (RBAC):

• RBAC-A: Is member of ROLE_DEVELOPER or

• RBAC-B: Is member of CAN_APP_<app.name> of the according app and ROLE_USER.

This is the default in case no permissions attribute is defined in the app config. This default can be overwritten by specifying the permissions attribute in the form config. In this case the RBAC-B will be ignored. Instead RBAC-C applies:

• RBAC-C: User is member of CAN_APP_<app.name> and at least one of the given permission rules is valid.

Example:

{
  ...
  "permissions": {
    "read": ["ROLE_GUEST"]
  }
}

The attribute read defines a list of permission strings the currently logged-in user must match at least one of. By default such a permission string is the name of a required role. In this example, any logged-in user assigned to ROLE_GUEST and CAN_APP_<app.name> is able to see this form. In case the user is assigned to ROLE_DEVELOPER he can also see this form since this will always apply.

PIPEFORCE URIs as permissions

Furthermore, also PIPEFORCE URI prefixes are supported to define permissions such as:

• $uri:group:<groupname> = Logged-in user must be member of group with name <groupname>.

• $uri:role:<rolename> = Logged-in user must have assigned this role (this is used by default also if no such prefix is used.)

Example:

{
  "type": "object",...
  "propertiespermissions": {
    "firstNameread": {
      "type": "string",["ROLE_DEVELOPER", "$uri:group:supervisors"]
      "title": "First Name",
      "description": "The first name of the person."
    },
    "lastName}
}

schema

The schema attribute defines a PIPEFORCE URI which is called in order to retrieve the Form schema for this form.

For example, the attribute could look like this:

"schema": "$uri:property:global/app/tld.domain.myapp/object/person/v1/schema"

Which could return a JSON schema like this:

{
  "type": "object",
  "properties": {
    "firstName": {
      "type": "string",
      "title": "LastFirst Name",
      "description": "The lastfirst name of the person."
    },
    "agelastName": {
      "type": "numberstring",  
          "title": "AgeLast Name",
      "description": "The last agename of the person."
    },
    "genderage": {
      "type": "stringnumber",      
      "title": "GenderAge",
      "description": "The genderage of the person.",
    },
    "enumgender": [{
       "type": "malestring",
      "title":  "femaleGender",

       "neutraldescription": "The gender of the person.",
      "enum": [
        "male",
        "female",
        "neutral"
      ]
    },
    "birthDate": {
      "type": "string",
      "format": "date",
      "title": "Date of birth",
      "description": "The date of birth of the person."
    }
  }
}

...

The output defines the path in the property store where the form data must be stored as JSON property after the form has been submitted. Example:

input"output": "$uri:property:global/app/tld.domain.myapp/objectdata/person/v1/instance/"

Since path ends in a slash / the form framework identifies this as a new property creation and automatically appends the uuid of the new property as “filename” at the end of the path (since version 10). In versions < 10, you had to add the PE ${vars.property.uuid}

...

The PE variable at the end. This PE will be interpreted on the server side and replaced by the UUID of the property. This approach is deprecated and will be removed soon.

The form handling pipeline can listen to a property.created event on this path then in order to get informed when a new property was created on this path:

pipeline:
  - event.listen:
      eventKey: property.created
      filter: ${body.target.path.contains('/tld.domain.myapp/objectdata/person/v1/instance/')}

The same way it works with property.updated event.

...

"input": "$uri:property:global/app/tld.domain.myapp/objectdata/person/v1/instance/fe97df"

Which could return a form data (= model) as JSON to be edited similar to this:

...

{
  "title": "Person Form",
  "description": "A simple person form.",  
  ...
  
  "layout": {
    "orientation": "horizontal",
    "items": [
      {
        "orientation": "horizontal","vertical",
        "items": [
          {"field": "firstName"},
          {"field": "age"}
        ]
      },
      {
        "orientation": "vertical",
        "items": [
          {"field": "lastName"},
          {"field": "gender"}
        ]
      }
    ]
  } 
}

This example would produce a form with nested orientations like the one shown below:

...

field

Inside a layout element you can place field elements pointing to field ids (widgets). This element can contain additional attributes like these:

hidden

If set to true, the widget is not shown in the form, but the value from the input is sent to the backend on submit. Example:

     "items": [ ...
      {
        "orientation": "vertical",
        "items": [
          {"field": "age", "firstNamehidden": true},
        ]
   {"field": "age"}  },
      ]...

readonly

If set to true, the widget value cannot be changed. Example:

      ...
},       {
        "orientation": "vertical",
        "items": [
          {"field": "lastNameage"},
          {"fieldreadonly": "gender"true}
        ]
      }
    ],
  }  }

This example would produce a form with nested orientations like the one shown below:

...

field

Inside a layout element you can place field elements pointing to field ids (widgets). This element can contain additional attributes like these:

hidden

...

  ...

height

Sets the height of this field, overwriting the default value in case the widget supports this attribute.

Example:

      ...
      {
        "orientation": "vertical",
        "items": [
          {"field": "agefirstName", "hiddenheight": true20}
        ]
      },
      ...

readonly

...

width

Sets the width of this field, overwriting the default value in case the widget supports this attribute.

Example:

      ...
      {
        "orientation": "vertical",
        "items": [
          {"field": "agefirstName", "readonlywidth": true30}
        ]
      },
      ...

Grouping with title and border

...

Internationalization (i18n)

TODOThe title and description of a form and also its validation messages can be internationalized (= translated to different languages). See here for more details, how this works: Internationalization (i18n).

Special Form Types

Document Understand Form (with AI support)

TODO

Variable substitution

...