Group Actions
Group actions allow applying an action simultaneously to multiple journal records: to selected records, to filtered results, or to specific records. They are defined in the journal configuration in the actions field and are managed through the ActionsExecutor implementation on the UI side.
To add group actions in the new journal configuration, use the actions (List<RecordRef>) field.
Actions from this list can be group actions, actions for filtered items, actions for specific records, or any combination of these capabilities.
Whether an action can be executed is determined by the ActionsExecutor implementation on the UI and flags in the action configuration. Example action on UI:
export default class DeleteAction extends ActionsExecutor {
static ACTION_ID = 'delete';
async execForRecord(record, action, context) {
return this.execForRecords([record], action, context);
}
async execForRecords(records, action, context) {
let dialogTitle, dialogText;
if (records.length === 1) {
dialogTitle = 'record-action.delete.dialog.title.remove-one';
dialogText = 'record-action.delete.dialog.title.remove-one';
} else {
dialogTitle = 'record-action.delete.dialog.title.remove-many';
dialogText = 'record-action.delete.dialog.msg.remove-many';
}
return new Promise(resolve => {
dialogManager.showRemoveDialog({
title: dialogTitle,
text: dialogText,
onDelete: () => {
Records.remove(records)
.then(() => {
resolve(true);
})
.catch(e => {
dialogManager.showInfoDialog({
title: 'record-action.delete.dialog.title.error',
text: e.message || 'record-action.delete.dialog.msg.error',
onClose: () => {
resolve(false);
}
});
console.error(e);
});
},
onCancel: () => {
resolve(false);
}
});
});
}
getDefaultActionModel() {
return {
name: 'record-action.name.delete',
icon: 'icon-delete',
theme: 'danger'
};
}
}
The executor implements two methods: execForRecords and execForRecord. This means that in the action configuration we can control these features by enabling and disabling them.
The execForQuery feature will always be inactive until the corresponding method is implemented.
By default, all features are enabled to the maximum extent if the corresponding Executor overrides the required methods.
Example action configuration:
{
"id": "download-zip",
"type": "download-zip",
"evaluator": {
"type": "has-attribute",
"config": {
"attribute": "_content"
}
},
"features": {
"execForQuery": false,
"execForRecord": false,
"execForRecords": true
}
}
The new journal configuration DTO has a groupActions field, but it is deprecated and will be removed in the future.
To replicate the same functionality as in groupActions, configure approximately the following:
Before:
<group-actions>
<action id="complete-document-task" title="journal.group-action.payments.approve">
<param name="actionId">complete-document-task</param>
<param name="tasks">[
{"taskId": "confirm-task", "transition": "Confirmed"}
]</param>
</action>
</group-actions>
After:
{
"id": "complete-confirm-task", <-- данный id не одно и то же что в старом конфиге. Следует задавать его по смыслу.
"type": "server-group-action",
"name": "journal.group-action.payments.approve",
"config": {
"id": "complete-document-task", <-- здесь уже id из группового действия
"formKey": "...", <-- в примере выше формы нет, но её следует помещать сюда, если нужен минимум действий при миграции. По-хорошему функционал форм для действий следует использовать из статьи с действиями
"params": {
"tasks": "[{ \"taskId\": \"confirm-task\", \"transition\": \"Confirmed\" }]", <-- проверить без кавычек; если получится — предпочтительный вариант
"actionId": "complete-document-task"
}
}
}