Flowable引擎使用統一許可權管理
工作流引擎Flowable是從Activiti引擎Fork出來的一個版本,它更加友好,且與Activiti完全相容,值得推薦(事實上是因為訪問flowable.org比訪問activiti.org要快一些)。本文討論的方案均可用於Activiti引擎。
因為Flowable有自己的一套使用者許可權體系,但是我們的業務系統都會提供更完善的使用者許可權,所以,整合這兩套使用者就是一個我們在實踐中必須要解決的問題。官方提供的方案無外乎三個:一是同步使用者資料;二是擴充套件程式碼,實現自己的UserEntityManager等;三是用檢視取代原來的幾個表。很顯然,方案三是最簡單的,完全不需要寫程式碼。
本文討論的就是方案三。Flowable提供的許可權體系比較簡單:使用者User-組Group,但我們的業務系統卻是:使用者User-部門Group-角色Role。比如,我們會有『組織部祕書』或『組織部部長』這樣的區分,而原來的Flowable則只有簡單的『管理員』或『使用者』,我們需要做的事情就是如何將『部門-角色』對映到『Group』。
下面我們就切入正題,說說如何具體實現使用者檢視取代表來解決兩個系統的統一使用者認證。
首先,我們先將Flowable中的三張表改名:
原表名 | 新表名 |
---|---|
ACT_ID_USER | XXX_ACT_ID_USER |
ACT_ID_GROUP | XXX_ACT_ID_GROUP |
ACT_ID_MEMBERSHIP | XXX_ACT_ID_MEMBERSHIP |
我們有這樣的幾張業務表需要對映到Flowable中,下面分述之。
使用者表(t_user)
欄位名 | 說明 |
---|---|
id | 使用者ID |
login_name | 登入名(賬號) |
real_name | 真實姓名(顯示名稱) |
郵箱 | |
avatar_url | 頭像ID |
有一個密碼欄位,因為我們的業務表中加密儲存而在Flowable中卻是明文,所以,需要特殊處理,所以這裡不需要考慮,直接用000000來做密碼。我們將它對映到Flowable中的使用者表,可以建立一個檢視,命名為ACT_ID_USER,語句下所示(為方便起見僅給出select子句)。
select
t1.login_name as ID_,
t1.login_type as REV_,
t1.real_name as FIRST_,
concat('',t1.id) as LAST_,
t1.email as EMAIL_,
'000000' as PWD_,
t1.avatar_url as PICTURE_ID_
from oa_system.t_user t1
union
select ID_,REV_,FIRST_,LAST_,EMAIL_,PWD_,PICTURE_ID_
from XXXX_ACT_ID_USER
這裡我們將前面改名為xxx_act_id_user的表也通過union包進來,可以包含原來的那些DEMO使用者,如果不需要,可以省略這個union。
部門表(t_group)
欄位名 | 說明 |
---|---|
id | 部門ID |
pid | 上級部門ID |
group_name | 部門名稱 |
group_master_id | 部門分管校領導ID |
這裡的group_master_id用於記錄該部門的分管校領導,是除部門領導之外的另一個會影響到使用者許可權的欄位。
角色表(t_role)
欄位名 | 說明 |
---|---|
id | 角色ID |
role_code | 角色程式碼 |
role_name | 角色名稱(用於顯示) |
然後,我們需要將這兩張表進行合併,以對映到Flowable的Group中,所以可以這樣做:
select
concat(t1.id,':',t2.role_code) as ID_,
1 as REV_,
concat(t1.group_name,':',t2.role_name) as NAME_,
case when t1.id=1 and t2.role_code='system' then 'security-role'
else 'assignment' end as TYPE_
from oa_system.t_group t1,oa_system.t_role t2
union
select ID_,REV_,NAME_,TYPE_
from XXXX_ACT_ID_GROUP
我們用冒號作為組ID與角色的分隔符,比如 4:security 表示ID為4的部門的祕書角色,並且將它作為Flowable中的Group的ID,同時,需要考慮我們業務表中有一個角色叫system,是系統管理員,所以將它也作為Flowable中的管理員。
如此一來,我們會得到一張大表(檢視),N個部門*M個角色的記錄數。
關係表(t_group_role_user)
欄位名 | 說明 |
---|---|
group_id | 部門ID |
role_id | 角色ID |
user_id | 使用者ID |
很明顯,我們的使用者是可以在不同部門扮演不同的角色。同樣,我們也將它對映到Flowable中去。
select
t3.login_name as USER_ID_,
concat(t1.group_id,':',t2.role_code) as GROUP_ID_
from oa_system.t_group_role_user t1
left join oa_system.t_role t2 on t1.role_id=t2.id
left join oa_system.t_user t3 on t3.id=t1.user_id
union
select
t2.login_name as USER_ID_,
concat(t1.id,':president') as GROUP_ID_
from oa_system.t_group t1 left join oa_system.t_user t2 on t1.group_master_id=t2.id
where t1.group_master_id is not null
union
select USER_ID_,GROUP_ID_ from XXXX_ACT_ID_MEMBERSHIP
這裡我們union了三個查詢子句,其中第二個就是用來處理部門的分管校領導這個概念。因為部門正常的領導是manager,所以,如果使用者被分配到該部門的president,就是將他作為分管領導配置的。
至此,我們用檢視實現了三張表USER,GROUP,MEMBERSHIP,現在可以使用業務系統中的使用者正常訪問Flowable了。
比如,我們可以這樣動態配置candidateGroups=”12:security”。