Record views allow to show the content of a record. It is possible to decide which fields will be displayed, override default display options, indicate which actions can be executed, etc.
Label
This is a human-readable name of the view. You can use spaces, special characters and mix upper case and lower case letters.
This label will be displayed at the top of the grid view, so make sure you use something users will understand.
Name
This is the internal name of the view. It cannot hold special characters or spaces.
Usually you will use the name of the view in scripts and the REST API, so changing it might affect your app and you will need to make some manual adjustments.
Entity
This is the entity the view will point to. Only records in this entity can be displayed by the view.
Type
The type indicates what the record view will be used for. Options are:
Read only: in this case the view won’t have any editable field (fields will be forced to be read only). However this type of record view is the only one that supports the execution of actions on the record (you cannot execute actions of edit or create views). This way, when this feature is enabled the optionShow actionsbecomes available and you have these options:All: all actions will be available to be executed in this view. Of course permissions and preconditions of actions will be verified. Also keep in mind that the default view of each action will be used.Some: if you just want to allow a few actions to be executed in this view, you can manually select which ones should be available (by selecting a action views).None: no actions will be available in this view.
Create: allows to create a new record. In this case fields can be editable (you could also have read only fields) and there will be buttons to create the record or cancel it.Edit: allows to edit an existing record. You can have editable fields as well as read only fields, and there will be buttons to save or cancel changes.
Managed
If this feature is enabled, when a field is added to the entity the view points to, it will be automatically added to the view as well.
This flag is set by default as it is very convenient to speed up development as you don’t need to worry that much about views and focus on the model.
If you disable this feature you will need to take care of adding new fields. Deleting or updating fields in the entity will still propagate changes to the view, but new fields need to be handled manually.
Show refresh button
Shows a Refresh button that allows to refresh record data without having to reload the entire page.
This flag is set by default.
Automatic refresh
When this flag is enabled a dynamic listener will be created to allow to refresh automatically this view for all users if a record that belong to the entity that this view is pointing is updated. No mather if the event is being fired by a user or a script. This configuration option will be available only if the parent collection (grid or card) view doesn’t have already enabled this feature or there is no parent view.
Alert for unsaved changes
When this flag is enabled, the user will see a message each time that tries to leave the form once he make a change
on some field. The only way to leave the form with unsaved changes without seeing the warning is by using the cancel
button. The message allows to continue with the record edition or discard the changes and continue with navigation.
This works for create and edit views and is enabled by default.
Form layout
Allow define how labels and fields are rendered on the form. It can be Horizontal in which case the label is rendered
at left side of the input field or can be Vertical in which case the label is rendered at the top of the field.
Fields
This is the list of fields that will be displayed on the view. It is possible to sort them, remove the ones you don’t need, etc.
Here it is possible to override default display options. You can check the documentation of General display options for more information.
Events
Events allow to customize the behavior of the UI.
These events only applied to the view, which means they are only triggered when using the app from the UI and not from the REST API.
Before show
This event is triggered before showing the record to the user. For example you could make some changes to the record before showing the record or log that the user opened the record.
Parameters
| Name | Type | Description |
|---|---|---|
record |
This is the record that will be displayed in the view. You can make changes to it and they will be applied in the UI. You don’t need to save those changes. If you do, those changes will be made permanent. |
Samples
// suggests a new value for a field
sys.logs.info('attempt to set a task as urgent');
record.field('urgent').val(true);
record.field('assignee').val(sys.context.getCurrentUser());
After create
This event is triggered after a record is created successfully by the user. This might useful in situations like it is required to navigate to other view or display a custom message.
Parameters
| Name | Type | Description |
|---|---|---|
record |
This is the just created record from the view. |
Samples
// logs message and navigate to other view
sys.logs.info('Record '+record.field('name').val()+' created successfully');
sys.ui.sendMessage({
scope: 'global',
name: 'navigate',
view: 'dashboard'
});
On record change
This event is triggered every time that a field change it’s value. For example you could make some changes to a record field depending on the value that another field has.
Parameters
| Name | Type | Description |
|---|---|---|
record |
This is the record that will be displayed in the view. You can make changes to it and they will be applied in the UI. You don’t need to save those changes. If you do, those changes will be made permanent. |
|
modifiedField |
|
This is the field path that fires the record refresh in the view. |
Samples
// suggests a new value for a field
if (!record.field('myLabel').isEmpty() && record.field('name').isEmpty()) {
record.field('name').val(record.field('myLabel').val());
sys.logs.info('Since name is empty and myLabel is not, we will set the value using the one from myLabel field: ' + record.field('myLabel'));
}
After save
This event is triggered after a record is saved successfully by the user. For example, this event can be used to navigate to a different view or to display a message.
Parameters
| Name | Type | Description |
|---|---|---|
record |
Updated record from the view. |
Samples
// logs message and navigate to the dashboard view
sys.logs.info('Record '+record.field('name').val()+' saved successfully');
sys.ui.sendMessage({
scope: 'global',
name: 'navigate',
view: 'dashboard'
});
Permissions
Permissions allow to define which groups can access this view.
Permissions for a view can be handled right in the view definition, but it is just a different view of what you can configure in groups. It is oriented so you can easily configure permissions on the view for all existing groups.
When a new view is created, if a group has permissions to the entity associated to that view, then the view receives permission to be used for that group.
For more information about permissions please refer to Groups.