jxTMS--角色

角色

角色是jxTMS中最爲重要的基礎性概念之一。角色在jxTMS中等同於如下幾個概念的綜合：

• 崗位，設置了一個角色，就意味着需要指派一個用戶來直接或間接的承擔該角色

• 職能，要幹什麼，一個角色所有的入口許可和自己所關聯的流程中的某節點、興趣點，就是本角色所需完成的工作內容

• 職權，能幹什麼，jxTMS以角色匹配來進行用戶操作的授權許可，即某入口允許某權限，則在某用戶請求時，檢查該用戶是否映射了該角色

正是由於jxTMS中的角色同時承擔了這麼多的任務，所以jxTMS中的角色，進一步的區分爲兩種：

• 真實角色：可以直接映射爲某人員的角色

• 虛擬角色：不可以直接映射爲人員而只能映射給某真實角色的角色

可以這麼理解，真實角色就是崗位，其必須指派給某個具體的人員，否則運行時可能因爲人員可執行分配的任務誘發各種問題，如前述簡易流程中，如果某節點未找到具體的執行人員，則會以accept放行該節點，就是出於爲了規避由於未映射人員而導致流程卡住。

而虛擬角色只是用來進行業務簡化設計的，如之前也講述過，報銷審批流程，一般在申請人填寫後，都是部門經理審批，可銷售部經理和技術部經理顯然不可能會是一個人，那難道銷售部和技術部就得分別設計一個流程嗎？這顯然是不合理的，所以就需要一個部門經理的虛擬角色作爲執行部門經理審批這一環節的執行角色，真正要分發角色時，再根據發起人所在的部門來確定到底是哪一個部門的部門經理。

由於這個兩層次角色映射的存在，建議流程、各業務模塊等都採用專用的虛擬角色，然後統一映射到代表崗位的真實角色上，這樣既不影響人員進出和調崗【即人員崗位變動時只需要簡單將其真實角色取消映射然後再映射給相應人員就可以了】，同時在崗位職能需要調整時也會是非常簡單的事：先撤銷原崗位到業務角色的映射，然後增加新崗位到業務角色的映射就可以了。

當然，爲了簡化操作，jxTMS沒有嚴格限制一人一崗，即一個成員可以爲其映射多個真實角色。如，某人可以是CTO，當然也可以是技術委員會主席，還可以是某技術小組的組長。但這就帶來了一個問題，該人在發起一個申請的時候，到底該如何判斷其屬於那個部門然後來依次確定後面各節點的虛擬角色應該映射到哪個部門的真實角色呢？！

jxTMS針對這個問題，引入了一個主角色的概念，即某人如果同時承擔了多個崗位，則應在這些崗位中選擇一個主要的崗位作爲主角色，以便於其在執行大多數的工作時便於確定相關的各種真實角色。

此外，jxTMS並不限制在需要指定所需角色時必須是真實角色還是虛擬角色，在任何需要角色的時候，不管真實角色還是虛擬角色，開發者都可以根據需要指定。jxTMS會根據實際情況，根據上下文來確定該角色具體映射到了哪個具體的員工。

這裏要說明的就是，如果一個真實角色映射了多個員工，在需要將這個真實角色映射爲具體人員時，目前jxTMS不承諾具體的指派策略，因爲需要爲根據不同的業務場景開發多種指派策略進行適配，所以目前不做任何承諾以保留未來的彈性。

在指派人員時，如果某個虛擬角色在發起者所在部門未找到相應的真實角色，如報銷審批流程中，有一個總監審批節點，則軟件部門不會有軟件總監，這時，jxTMS就會上溯到上級部門中檢查是否存在相應的真實角色，如此一直上溯直到能確定或一直到最高曾經也未找到。如這裏所說的總監審批，軟件部門人員發起的可能會找到技術總監進行審批，銷售發起的就會找到銷售總監進行審批。

可能就會有人問了，如果就是技術總監發起的申請呢？！很簡單，技術總監發起的申請，在部門經理審批環節，由於技術總監所在部門層級高，沒有部門經理，越往上越不會有這一個角色，所以經過上溯查找後就是找不到一個真實的部門經理來執行該節點，而前面反覆說了，一個節點沒找到執行人員，就會自動以accept放行，所以就不需要部門經理審批了，這也恰恰符合了流程審批的權限邏輯：即領導不應由自己的下屬來審批其活動。

那麼，當這個流程推進到總監審批節點，那是否會自己審批自己發起的申請呢？！這要看這個節點的業務性質：

• 如果是覈驗性質的業務環節，即用來確認業務行爲的真實性、準確性的，則自然不存在自己不相信自己的問題，那就設置canJump允許跳過

• 如果是批准性質的業務環節，即用來確認資源分配、權限授予等業務控制的，即這個環節是用來確認業務操作是否合規合法的，自然就必須執行而不論是誰都不可以跳過

在用戶點擊了某入口發起一個請求時，jxTMS會檢查該用戶是否和該入口所指定的角色進行匹配，也就是說，jxTMS會羅列該用戶所有的真實角色、虛擬角色，然後和該入口的所指定的所有角色進行匹配檢查，只要有一個能匹配成功就認爲授權通過。所以這個權限檢查過程是非常消耗計算資源的。爲此，jxTMS會緩存用戶所有的角色，以最大限度的降低這個非常高頻的權限檢查的計算開銷。

如果開發者在入口定義時未指定角色，則默認該入口是所有人都可以操作的。

此外，如下幾種情況是可以豁免權限檢查的：

• search，分頁查詢時讀取當前頁面數據，因是嵌入分頁查詢邏輯中的，如果前置查詢入口未授權，自然本入口也無法得到正確執行，所以該操作所有人都可以執行

• reSearch，分頁查詢時重置查詢條件，因是嵌入分頁查詢邏輯中的，如果前置查詢入口未授權，自然本入口也無法得到正確執行，所以該操作所有人都可以執行

• 如果是被鏈接到當前界面工具條中的入口，既然主界面被允許顯示給用戶了，這些工具條也自然應該是允許執行的

• 開發者是組容器、容器表中定義的按鈕等，自然也是這些容器都被允許顯示給用戶了，其自然也就是允許的

• 數據表中那些操作列中代碼動態生成的入口，自然也是連數據表都允許顯示給用戶了，其自然也就是允許的

部門

曾幾何時，筆者非常看重部門，把部門視爲組織中資源管理的切入點，把大量的東東都集中於部門。但後來發現，這種思路會導致爲順應企業管理而對系統所進行的配置管理非常繁瑣，可能就是一個簡單的崗位調整，就會導致非常多的相關配置調整。而隨着筆者逐步加深了對角色的認識，最終筆者終於認識到組織中角色纔是配置管理的核心，一切操作圍繞角色來展開，而部門只是爲角色提供一個錨定點，即用於追溯部門-子部門這一關係而將相應的虛擬角色定位到正確的真實角色。

也就是說，部門就是用於容納兩個關係的容器：

• 部門-真實角色，這是部門存在的最大理由

• 部門-子部門，這是映射組織架構而確定管理層級

因此，jxTMS在創建一個組織的時候，同時會創建一個和組織同名的部門作爲所有上溯行爲的終點，然後按組織架構形成部門-子部門的關係，然後爲每個真實角色指定所在部門，則部門即完成了相關使命。考慮到這一點，目前發佈的jxTMS中甚至已經去掉了部門的任何管理操作，只是在導入角色的時候爲其同步設置部門與上級部門，也就是說，目前的jxTMS中，部門已經被視爲角色的一個屬性了【當時在數據庫中是存在相應的數據表進行管理的】。其架構調整，也隨之由導入角色這一操作同步進行。

也就是說，如果需要調整部門架構或崗位調整等，需要把【導入文檔模板->importRole.xls，導入文檔模板->importUser.xls】這兩個文件進行修改，然後先導入角色再導入人員即可。

目前，jxTMS已經打包爲雲服務器鏡像，開發者開箱即用：
jxTMS-騰訊雲市場​