On this page
The Settings tab is used to configure general settings for app (app type, permissions and listing style), it is also used to create custom fields to store app settings for each site.
App Type: determine whether the app is a
App Handler: in the case of Remote App/Widget, an API endpoint can be specified to handle data.
Screenshot: specify a screenshot or an icon for the app which will be shown with the app when it is listed on SiteGUI Appstore or each Site's activated Apps.
Listing Style: choose how to display multiple records when accessing the app's main page.
Tick Button's Action: enter URL encoded params to update an app's record when it is ticked. Leave blank to disable Tick button. One example for Tick button is a Todo app where you can tick a Todo entry to mark it as Done. Tips: when a record is ticked, the frontend will send the params to the server, if it is successful, the frontend will attempt to move the record to a Kanban board associated with the value of the first param (Kanban view only).
Menu Category: which category the app should belongs to.
Every app has three stakeholder groups: Client, Staff and Guest (public, non-registered user). Clients are the main users of the app who can create a new record and view their own records (created by or on behalf of them), Staff are those who can manage records and Guest can view all published records if the app allows it. SiteGUI app can be built to serve different stakeholder groups, including guests/non-registered users (Documentation app), Clients (Support Ticket Tracker app), both registered and non-registered users (Feature Request app) and Staff only (Task Management app). Choosing suitable App Users for each app makes this possible.
App Users: if the app is built for Customers to use, besides enabling Client Permissions (Read/Write/Delete), developers should also include Client as App Users in order to make the app accessible at the Customer Portal at https://my.company.domain/account, this is where Customers can access all the apps made available for them. If App Users does not include *Client*, Customer access will be denied. Similarly, if the app is built for Guests to view published records, developers should include Guest as App Users in order to make the app viewable at https://company.domain/app_name, this is where Guest can access all the app's published records. If the Client Read permission is not enabled, Guest access will be denied. Please note that for App Users, Client strictly refers to Customers, only include Client as App Users if you do want Customers to access the app at the Customer Portal.
Publish Client's Post Automatically: app records need to be published (App Users should include Guest and Client Read permission must be enabled) before unregistered users can view them on the website (e.g: https://company.domain/app/app_name/record_slug). Normally, Clients do not have permission to publish records but for some apps, it is not necessary to moderate records created by Clients. By enabling this feature, new records created by Clients are published automatically without having to wait for Staff to do that.
Record Versioning: this enables versioning for published records. When a staff with no publish or management privilege tries to save an already-published-record (public access can be blocked by not including Guest in App Users), a new version of the record is cloned instead, allowing the staff to make changes to the cloned version without changing the original one. Later, the staff may choose Request Merge to request privileged staff to update the original version with their modified version. For privileged staff, they can replace the original version with any version by choosing Replace The Original Version With This Version when viewing the choose version. Please note that versioning just clones the record content only, it doesn't clone the record's subapp entries or the original record's relationship (menu, widget etc). When updating, versioning will preserve the original record's ID, slug, view, public data and subapp entries/relationships. The Request Merge action should be handled by Automated Actions to notify privileged staff or request their approval when the event occurs (when the poster is not a supervisor but requesting to publish the record)
Staff Permissions: if you don't want all Staff to access or manage app records, you can always use Staff Permissions to limit access to certain staff group. By specifying Create permission, you'll limit creating and listing records to those staff having that permission. Only those having specified Manage permission are allowed to manage app records, other staff will not be able to manage them. This is app level permission, meaning that it applies to all app records.
Client Permissions: if your app allows only certain customer group to access or manage app records, you can use Client Permissions to limit access to certain customer group. By setting Read or Write permission to a Group::Group_Name, you'll limit listing/reading or creating/updating records to those customers in the Group_Name group. For apps without this Read permission set, customers can list/read only app records they created or are assigned to them. However for apps having this Read permission set, customers in the associated group will be able to list/read any unprotected app records including records created by staff or other customers.
Page Level Permission: page/record level permission applies to each individual record staticly or dynamically. If a static permission (e.g: Product::create) is specified then only staff having that permission (besides app level permission) can read the record. In some situations, the permission must be set dynamically depending on another value chosen when creating the record. In that case, dynamic mapping the value to the permission is needed. The mapping table cannot be specified when the app is built but when the app is configured for each site. The Per Site Settings section below will help setting up the mapping table by creating a config fieldset to let Site Managers to enter 1 to 1 mapping of values to permissions when configuring the app.
Here is an example to illustrate how dynamic permission mapping works: a Ticket Tracker app has a custom config fieldset that includes department and permission as the properties and dynamic mapping is set to depend on the department's value. A company using this app has three departments: Sales, Billing and Tech. Sales staff has permission Product::create, Billing staff has permission Invoice::create and Tech staff has permission Role::Tech exclusively. When configuring Ticket Tracker app for this company, we can enter department Sales and permission Product::create to create a mapping, do the same for Billing and Tech. When the app is used and the Customer chooses Sales department, the dynamic mapping will kick in and select the associated permission which is Product::create for that record. As the permission is set, besides the Customer creating that ticket, only Sales staff can read the ticket because they have that permission.
As app is built to use on multiple Sites, some Settings need to be specified by Site Managers rather than the app developer. App developers may create custom Settings fields for storing app settings for each site. SiteGUI App Builder has many predefined fields such as
To create a custom field, just choose a field type, name (id), label (display name) and description (optional) for it. You can also set field visibility, a default value, whether the field is required or optional or accepting multiple values (select and lookup field only), and specify options if field supports them.
For field that accepts multiple text-input values (not selectable values), it should be added as a fieldset field. For example: an app allowing Site Managers to specify their own statuses can create a custom field named status and make it a fieldset field. When configuring the app, Site Managers can add multiple statuses as they like. Multiple fields can be added to a fieldset if they all need multiple values, the values for each field will be consolidated to remove duplicated entries from the list of values.
If a field named permission is added to a fieldset, its value can be used for Page Level Permission's dynamic mapping if Page Level Permission is set to map to another field in the fieldset. For example a field named department is in the fieldset and dynamic mapping is set to department, then when a new records is created, depending on the value of department (department should be an input field as well), the associated permission will be chosen for that record.
Finally, if you want to store the secret (client_secret) for your app securely (instead of hard coding), you may enter the secret as the default value for the Oauth field, this value will be stored and retrieved automatically when your application needs it. This needs to be done one time only and is effective immediately for Instant Apps, for normal Apps, the value will be saved when the App is configured for the first time.