Flujo de trabajo integrado de la plataforma de desarrollo de aplicaciones: diseño e implementación de permisos de formulario de proceso

fondo

Aprobación del proceso, generalmente correspondiente a un formulario comercial. Generalmente hay dos modos de implementación para este formulario: uno es que diferentes enlaces corresponden a diferentes formularios y el otro es hacer un formulario grande y dividirlo en diferentes áreas. Desde una perspectiva empresarial, el primero suele corresponder a un procesamiento empresarial complejo; este último es más común y un poco más utilizado, más amigable y más práctico.

La adopción de esta última solución requiere un control de permisos detallado sobre los atributos del formulario. En diferentes enlaces, existen diferentes requisitos para el mismo atributo, que se puede subdividir en tres permisos: invisible, de solo lectura y editable.

Diseño

Sería demasiado engorroso controlar directamente cada atributo, por lo que se agrega agrupación de atributos para lograrlo, es decir, un grupo de atributos se empaqueta en un área y la configuración de permisos para el área afectará todos los atributos debajo de ella (tenga en cuenta que en el implementación, no hereda la configuración de la región a través de atributos, sino la configuración de la región, si no es visible, los atributos subordinados también serán invisibles).

Controla los permisos del área del formulario. Las diferentes áreas tienen tres permisos: invisible, de solo lectura y editable en diferentes enlaces.

Por ejemplo, el mismo formulario de reembolso: cuando un empleado completa el formulario de reembolso, solo puede completar la información principal y los detalles del formulario de reembolso, y el resto de la información es invisible; cuando el gerente lo aprueba, solo puede completar la auditoría
. resultados y opiniones, y el cuerpo principal y los detalles de la Vista;
durante la aprobación financiera, los detalles del asunto del formulario de reembolso y la información de revisión del gerente solo se pueden ver, y solo se puede configurar la información relacionada con si se reciben o no los gastos.

En resumen, al configurar diferentes áreas y agrupar atributos por área, se simplifica el control de autoridad (directamente a atributos sin agrupar, porque la configuración es demasiado engorrosa), y luego, a través de la identificación del área, haciendo coincidir con la identificación del enlace, la autoridad está preestablecido en tres tipos: invisible, de solo lectura y editable.

El trabajo específico es el siguiente:
1. En la gestión de elementos de autoridad, defina el área para el formulario
2. Al diseñar la plantilla de flujo de trabajo, después de seleccionar un enlace, lea la lista de áreas del formulario asociado con la plantilla de proceso y establezca la autoridad
3. Al manejar la tarea, lea la configuración de permisos del enlace, el control frontal es visible, de solo lectura y editable

Esto es equivalente al control de autoridad detallado del área, que puede manejar situaciones complejas y cambiantes. Por ejemplo, un determinado enlace puede editar múltiples áreas, porque la división del área no se ocupa de la agrupación de editabilidad según el enlace, pero desde el punto de vista empresarial campos de datos relacionados.

Cabe señalar que la configuración del elemento de permiso de back-end es un "área lógica" que puede no corresponderse con el "área física" en la página de inicio. Por ejemplo, en el siguiente formulario de solicitud de salida de back-end control de permisos, en realidad hay tres registros
imagen.png
.
imagen.png

El área de información básica no necesita control de permisos y es de solo lectura para todos, por lo que no es necesario registrarla como un elemento de permiso.
El llenado, la aprobación departamental y la aprobación del personal están en correspondencia uno a uno con las áreas de la interfaz de usuario.
Sin embargo, en algunos casos especiales, como un enlace que solo necesita modificar un número limitado de atributos en el formulario, estos atributos pueden pertenecer a una pequeña parte de un área de front-end determinada, y los puntos extremos pueden incluso distribuirse en diferente En el área, si el área en el elemento de permiso corresponde al área de la interfaz de usuario uno por uno, será difícil lidiar con ello. En este caso, es completamente posible registrar el área lógica en el elemento de permiso, controlar el atributo para controlar el permiso e incluso tratar un solo atributo como un área lógica. Si la propiedad es visible o no se verá afectada por las propiedades del área física, pero bajo la premisa de ser visible, ya sea que se pueda editar o no, la configuración de la propiedad tiene mayor prioridad.

Hay otra pequeña pregunta aquí: ¿el padre de la configuración regional es una plantilla de proceso o un formulario?
La plantilla de proceso y el documento comercial son relativamente independientes y están asociados entre sí a través del identificador del documento comercial. Las plantillas de proceso tienen múltiples versiones, mientras que los documentos comerciales no tienen versiones y están siempre actualizados. En términos de cohesión, los ámbitos se acercan más a los documentos comerciales. El modelado de plantillas de procesos y la configuración de permisos de formulario son solo para leer la definición de área del formulario asociado.

Camunda no admite el control de permisos detallado del formulario correspondiente al proceso, y la plataforma personaliza las tablas y funciones de la biblioteca para mejorarlo. En realidad, solo hay dos tipos de enlaces que deben configurarse con permisos de formulario, a saber, el enlace de inicio y el enlace de tarea del usuario. Otros tipos de nodos se procesan automáticamente sin participación humana, por lo que, naturalmente, no hay necesidad de control de permisos.

En realidad, hay otro lugar al que prestar atención aquí, es decir, convertimos el modelado del proceso en datos json. Cuando el proceso se migra (de desarrollo a prueba, de prueba a producción), lo implementamos exportando e importando, lo que significa Es decir, necesitamos configurar la información de permiso del enlace como parte de los datos json.

Implementación del sistema

Interfaz

Para la configuración del atributo de configuración del nodo iniciador y el nodo de administración, el subatributo permisoConfig se define para almacenar la información de configuración del permiso del enlace.

{
    
    
	"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": {
    
    }
	}
}

Como se muestra en la figura anterior, el nodo iniciador no necesita configurar el personal de administración, solo se debe configurar la autoridad del área de enlace, mientras que el nodo de administración necesita configurar el personal de administración y la autoridad del área de enlace al mismo tiempo.

El efecto del nodo iniciador es el siguiente:
inserte la descripción de la imagen aquí

El código fuente correspondiente es el siguiente:

<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>

extremo posterior

Utilice la función de configuración de código bajo de la plataforma para implementar la definición de entidad, de la siguiente manera:
imagen.png
Las propiedades de configuración son las siguientes:
imagen.png
luego genere tablas y códigos de biblioteca.

Información de la plataforma de desarrollo.

Nombre de la plataforma: Plataforma de desarrollo One Two Three
Introducción: Plataforma de desarrollo general de nivel empresarial
Información de diseño: columna csdn
Dirección de código abierto: Protocolo de código abierto Gitee
: El código abierto del MIT
no es fácil, bienvenido a favoritos, me gusta y comentarios.

Supongo que te gusta

Origin blog.csdn.net/seawaving/article/details/132321824
Recomendado
Clasificación