background
Process approval, usually corresponding to a business form. There are generally two implementation modes for this form. One is that different links correspond to different forms, and the other is to make a large form and divide it into different areas. From a business perspective, the former usually corresponds to complex business processing; the latter is more common and A little more commonly used, friendlier and more practical.
Adopting the latter solution requires fine-grained permission control on the attributes in the form. In different links, there are different requirements for the same attribute, which can be subdivided into three permissions: invisible, read-only, and editable.
Design
It would be too cumbersome to directly control each attribute, so attribute grouping is added to realize it, that is, a group of attributes is packaged into an area, and permission configuration for the area will affect all attributes under it (note that in the implementation , it does not inherit the configuration of the region through attributes, but the configuration of the region, if it is not visible, the subordinate attributes will also be invisible).
Control the area permissions of the form. Different areas have three permissions: invisible, read-only, and editable in different links.
For example, for the same reimbursement form: when an employee fills in the reimbursement form, he can only fill in the main information and details of the reimbursement form, and other information is invisible
; View;
during financial approval, the subject details of the reimbursement form and the manager's review information can only be viewed, and only information related to whether to receive expenses can be set.
To sum up, by setting different areas and grouping attributes by area, the authority control is simplified (directly to the attribute without grouping, because the configuration is too cumbersome), and then, through the area identification, matching with the link identification, the authority is preset to three types : invisible, read-only, editable.
The specific work is as follows:
1. In the authority item management, define the area for the form
2. When designing the workflow template, after selecting a link, read the area list of the form associated with the process template and set the authority
3. When handling the task , read link permission configuration, front-end control visible, read-only and editable
This is equivalent to the fine-grained authority control of the area, which can deal with complex and changeable situations. For example, a certain link can edit multiple areas, because the division of the area is not to deal with the editability grouping according to the link, but from the business point of view. related data fields.
It should be noted that the configuration of the back-end permission item is a "logical area", which may not correspond to the "physical area" in the front-end page. For example, in the following leave request form back-end permission control, there are actually three registrations
.
The basic information area does not need permission control and is read-only by everyone, so it does not need to be registered as a permission item.
Filling, departmental approval and personnel approval are in one-to-one correspondence with the areas of the front-end UI.
However, in some special cases, such as a link that only needs to modify a limited number of attributes on the form, these attributes may belong to a small part of a certain front-end area, and the extreme points may even be distributed in different In the area, if the area in the permission item corresponds to the front-end UI area one by one, it will be difficult to deal with it. In this case, it is completely possible to register the logical area in the permission item, control the attribute to control the permission, and even treat a single attribute as a logical area. Whether the property is visible or not will be affected by the properties of the physical area, but under the premise of being visible, whether it can be edited or not, the configuration on the property has a higher priority.
There is another small question here, is the parent of the locale a process template or a form?
The process template and the business document are relatively independent, and are associated together through the business document identifier. Process templates have multiple versions, while business documents are unversioned and always up to date. In terms of cohesion, areas are closer to business documents. Process template modeling, setting form permissions, is only to read the area definition of the associated form.
The fine-grained permission control of the form corresponding to the process is actually not supported by Camunda itself, and the platform customizes the library tables and functions to improve it. There are actually only two types of links that need to be configured with form permissions, namely, the initiation link and the user task link. Other types of nodes are processed automatically without human participation, so naturally there is no need for permission control.
There is actually another place to pay attention to here, that is, we convert the process modeling into json data. When the process is migrated (from development to test, from test to production), we implement it by exporting and importing, which means That is, we need to configure link permission information as part of the json data.
System implementation
front end
For the configuration attribute config of the initiator node and the management node, the sub-attribute permissionConfig is defined to store the link permission configuration information.
{
"name": "填报",
"id": "root",
"type": "ROOT",
"config": {
"permissionConfig": [{
"areaCode": "applyArea",
"permission": "EDITABLE"
}, {
"areaCode": "organizationApproval",
"permission": "READONLY"
}, {
"areaCode": "hrApproval",
"permission": "INVISIBLE"
}]
},
"branchList": [],
"child": {
"name": "办理环节",
"id": "node7228_430f_8872_8e08",
"type": "HANDLE",
"config": {
"personConfig": {
"mode": "NORMAL",
"setAssigneeFlag": "YES",
"userGroup": "99",
"userGroupName": "系统管理员"
},
"permissionConfig": [{
"areaCode": "applyArea",
"permission": "READONLY"
}, {
"areaCode": "organizationApproval",
"permission": "EDITABLE"
}, {
"areaCode": "hrApproval",
"permission": "INVISIBLE"
}]
},
"child": {
}
}
}
As shown in the figure above, the initiating node does not need to configure management personnel, only the link area authority needs to be set, while the management node needs to set the management personnel and link area authority at the same time.
The effect of the initiating node is as follows:
The corresponding source code is as follows:
<template>
<el-drawer
:append-to-body="true"
title="环节设置"
v-model="visible"
:show-close="false"
:size="550"
:before-close="close"
destroy-on-close
>
<el-collapse v-model="activeName">
<el-collapse-item title="权限设置" name="permissionConfig">
<el-table :data="permissionData" style="width: 100%" highlight-current-row border>
<el-table-column label="区域" width="120">
<template #default="scope">{
{ scope.row.areaName }}</template>
</el-table-column>
<el-table-column label="权限">
<template #default="scope">
<dictionary-radio-group
v-model="scope.row.permission"
code="NodePermissionCode"
class="form-item"
/>
</template>
</el-table-column>
</el-table>
</el-collapse-item>
</el-collapse>
<template #footer>
<el-button type="primary" @click="save">确 定</el-button>
<el-button @click="close">取 消</el-button>
</template>
</el-drawer>
</template>
<script>
import DictionaryRadioGroup from '@/components/abc/DictionarySelect/DictionaryRadioGroup.vue'
import { useStore } from '../../stores/index'
let store = useStore()
export default {
components: { DictionaryRadioGroup },
data() {
return {
activeName: ['permissionConfig'],
// 权限数据
permissionData: []
}
},
computed: {
visible() {
return store.rootNodeConfigVisible
},
rootNodeConfig() {
return store.rootNodeConfig
},
processDefinitionId() {
return store.processDefinitionId
}
},
watch: {
rootNodeConfig(value) {
// 加载权限设置
this.$api.workflow.workflowNodePermissionConfig
.getNodePermissionConfig(this.processDefinitionId, value.id)
.then((res) => {
if (res.data) {
this.permissionData = res.data
// 根据配置更新
const permissionConfig = value.config.permissionConfig
if (permissionConfig && permissionConfig.length > 0) {
this.permissionData.forEach((item) => {
permissionConfig.forEach((config) => {
if (config.areaCode == item.areaCode) {
item.permission = config.permission
return
}
})
})
}
}
})
}
},
methods: {
close() {
store.setRootNodeConfigVisible(false)
},
save() {
const permissionConfig = this.permissionData.map((item) => {
return {
areaCode: item.areaCode,
permission: item.permission
}
})
const nodeConfig = Object.assign(
store.rootNodeConfig,
{
config: { permissionConfig: permissionConfig }
},
{ flag: true }
)
store.setRootNodeConfig(nodeConfig)
this.close()
}
}
}
</script>
<style scoped></style>
rear end
Use the platform's low-code configuration function to implement entity definition, as follows:
Configuration properties are as follows:
Then generate library tables and codes.
Development platform information
Platform name: One Two Three Development Platform
Introduction: Enterprise-level general development platform
Design information: csdn column
Open source address: Gitee
open source protocol: MIT
open source is not easy, welcome to favorite, like, comment.