背景
プロセスの承認。通常はビジネス フォームに対応します。このフォームの実装形態には、大きく分けてフォームごとにリンクを対応させる方式と、大きなフォームを作成して領域ごとに分割する方式があり、ビジネスの観点から見ると、前者は複雑な業務処理に対応することが多い。後者の方が一般的で、もう少し一般的に使用され、親しみやすく実用的です。
後者のソリューションを採用するには、フォーム内の属性に対するきめ細かい権限制御が必要です。異なるリンクでは、同じ属性に対して異なる要件があり、非表示、読み取り専用、編集可能の 3 つの権限に細分化できます。
デザイン
各属性を直接制御するのは非常に面倒なので、それを実現するために属性グループ化が追加されます。つまり、属性のグループが 1 つのエリアにパッケージ化され、そのエリアの権限設定がその配下のすべての属性に影響します (実装では、属性を通じて領域の構成は継承されませんが、領域の構成が表示されない場合、下位の属性も非表示になります)。
フォームの領域権限を制御します。領域ごとに、非表示、読み取り専用、さまざまなリンクで編集可能という 3 つの権限があります。
たとえば、同じ償還フォームの場合: 従業員が償還フォームに記入する場合、従業員は償還フォームの主な情報と詳細のみを入力でき、その他の情報は表示されません。財務上の承認中、対象者の詳細は表示されませ
ん
。精算フォームと管理者のレビュー情報は閲覧のみ可能であり、経費の受け取りの有無に関する情報のみ設定可能です。
まとめると、異なる領域を設定し、領域ごとに属性をグループ化することで、権限制御を簡素化し（設定が面倒なのでグループ化せずに属性に直接）、領域識別、リンク識別との照合により、権限制御を簡素化します。は、非表示、読み取り専用、編集可能の 3 つのタイプにプリセットされています。
具体的な作業は以下の通りです。
1. 権限項目管理で、フォームの領域を定義します。
2. ワークフローテンプレート設計時に、リンクを選択後、プロセステンプレートに関連付けられたフォームの領域リストを読み込み、権限を設定します。
3. タスクを処理するとき、リンク許可設定の読み取り、フロントエンド コントロールの表示、読み取り専用および編集可能
これは、複雑で変化しやすい状況に対処できる、エリアのきめ細かい権限制御に相当します。たとえば、あるリンクは複数のエリアを編集できます。これは、エリアの分割は、次のような編集可能性のグループ化を扱うものではないためです。リンクですが、ビジネスの観点から見ると、関連するデータ フィールドです。
バックエンド許可項目の構成は「論理領域」であり、フロントエンド ページの「物理領域」に対応しない場合があることに注意してください。たとえば、次のような休暇リクエスト フォーム バックエンド権限制御には、実際には 3 つの登録があります
。
基本情報領域は権限制御が不要で誰でも読み取り専用のため、権限項目として登録する必要はありません。
入力、部門承認、人事承認はフロントエンドUIの領域と1対1に対応します。
ただし、フォーム上の限られた数の属性のみを変更する必要があるリンクなど、一部の特殊なケースでは、これらの属性は特定のフロントエンド領域のごく一部に属し、極値ポイントが分散されることもあります。領域が異なる場合、許可項目内の領域とフロントエンドUI領域がいちいち対応していると対応が難しくなります。この場合、論理領域をパーミッション項目に登録し、属性を制御してパーミッションを制御したり、単一の属性を論理領域として扱うことも完全に可能です。プロパティが表示されるかどうかは物理領域のプロパティに影響されますが、表示されることを前提として編集の可否に関わらず、プロパティ上の設定が優先されます。
ここでもう 1 つの小さな質問があります。ロケールの親はプロセス テンプレートですか、それともフォームですか?
プロセス テンプレートとビジネス ドキュメントは比較的独立しており、ビジネス ドキュメント ID を通じて関連付けられます。プロセス テンプレートには複数のバージョンがありますが、ビジネス ドキュメントはバージョン管理されておらず、常に最新です。まとまりという点では、ビジネス文書に近い領域です。プロセス テンプレート モデリングでは、フォームの権限を設定し、関連付けられたフォームの領域定義を読み取るだけです。
プロセスに応じたフォームのきめ細かな権限制御は実はCamunda自体ではサポートされておらず、プラットフォーム側でライブラリテーブルや関数をカスタマイズして改善しています。実際にフォームの権限を設定する必要があるリンクは、開始リンクとユーザータスクリンクの 2 種類だけであり、その他の種類のノードは人間の介入なしに自動的に処理されるため、当然のことながら権限制御は必要ありません。
実はここでもう一つ注目すべき点があり、プロセスモデリングをjsonデータに変換し、プロセスを移行（開発からテスト、テストから本番）する際に、エクスポートとインポートによって実装します。つまり、リンク許可情報を json データの一部として構成する必要があります。
システム導入
フロントエンド
イニシエータノードとマネジメントノードの構成属性configに対して、サブ属性permissionConfigが定義され、リンク許可構成情報が格納される。
{
"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": {
}
}
}
上図に示すように、開始ノードでは管理要員の設定は不要でリンクエリア権限のみを設定するだけでよく、管理ノードでは管理要員とリンクエリア権限を同時に設定する必要があります。
開始ノードの効果は次のとおりです。
対応するソースコードは次のとおりです。
<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>
後部
プラットフォームのローコード構成機能を使用して、次のようにエンティティ定義を実装します。
構成プロパティは次のとおりです。
次に、ライブラリ テーブルとコードを生成します。
開発プラットフォーム情報
プラットフォーム名: One Two Three 開発プラットフォーム
紹介: エンタープライズ レベルの総合開発プラットフォーム
設計情報: csdn コラム
オープン ソース アドレス: Gitee
オープン ソース プロトコル: MIT
オープン ソースは簡単ではありません。お気に入り、いいね、コメントへようこそ。