Homepage

Form

Last edit: Jun 10, 2024

Form configuration - deprecated, use Form

type Form implements AdminSharedAttributesInterface {
  api_call_notifications: [ApiCallNotification!]
  async_callback_actions: String
  async_callback_delay: String
  async_callback_max_attempts: Int
  async_callback_priority: AsyncCallbackPriority
  authorization_policies: [AuthorizationPolicy!]
  callback_actions: String
  configuration: HashObject
  created_at: JSONDate!
  default_payload: String
  email_notifications: [EmailNotification!]
  fields: HashObject
  flash_alert: String
  flash_notice: String
  id: ID!
  liquid_body: String
  manually_managed: Boolean
  metadata: HashObject
  name: String!
  physical_file_path: String
  redirect_to: String
  resource: String!
  resource_owner: String!
  response_headers: String
  sms_notifications: [SmsNotification!]
  spam_protection: HashObject
  updated_at: JSONDate!
}

Fields

api_call_notifications (ApiCallNotification)

associated api call notifications

async_callback_actions (String)

Same as callback, but invoked asynchronously. Recommended for performance reason.

async_callback_delay (String)

Delays invoking the job by specified number of minutes. Liquid allowed -
useful to invoke code at certain point in time, for example 1 hour before
something etc. To calculate proper number you can use time_diff filter.

async_callback_max_attempts (Int)

Defines max number of retrying attempts in case of an error. Usually you do not want to change it.

async_callback_priority (AsyncCallbackPriority)

defines the invocaction priority, the higher the quicker timeout

authorization_policies (AuthorizationPolicy)

associated authorization policies

callback_actions (String)

liquid code to be invoked after persisting input to DB. If possible, use async callback actions instead

configuration (HashObject)

whitelist of attributes which can be persisted in the DB. On server side
(callbacks, emails etc) you have access to submited values via form variable
(for exapmple configuration: properties: my_var is accessible via
form.properties.my_var )

created_at (JSONDate)

default_payload (String)

liquid code which has to evaluate to JSON. This extends/overwrites user
submitted input via form, before validation. Most useful to store in DB
sensitive data which you do not want user to modify, for example
context.current_user.id

email_notifications (EmailNotification)

associated email notifications

fields (HashObject)

whitelist of attributes which can be persisted in the DB. On server side
(callbacks, emails etc) you have access to submited values via form variable
(for exapmple fields: properties: my_var is accessible via
form.properties.my_var )

flash_alert (String)

Message which you want to display to user upon validation errors.Output is
available via context.flash_alert. Liquid allowed.

flash_notice (String)

Message which you want to display to user after successful form submission.
Output is available via context.flash_notice. Liquid allowed.

id (ID)

liquid_body (String)

liquid code to evaluate to valid form html. You have access to form_builder variable and form tag.

manually_managed (Boolean)

defines whether this objectwill be affected via pos-cli deploy / sync

metadata (HashObject)

name (String)

physical_file_path (String)

defines the physical path of the file

redirect_to (String)

Path or URL to which user should be redirected after successful form submission. Liquid allowed.

resource (String)

resource_owner (String)

defines who can submit the form. If set to anyone, please make sure to provide authorization_policies

response_headers (String)

Response headers for the form

sms_notifications (SmsNotification)

associated sms notifications

spam_protection (HashObject)

name of the strategy and configuration for them

updated_at (JSONDate)

Interfaces

AdminSharedAttributesInterface

Questions?

We are always happy to help with any questions you may have.

contact us