B端產(chǎn)品之權(quán)限設(shè)計(jì)(RBAC權(quán)限模型)
編輯導(dǎo)語:在B端管理系統(tǒng)中,“權(quán)限管理”是必不可少的功能,不同的系統(tǒng)中權(quán)限的應(yīng)用復(fù)雜程度不一樣,要根據(jù)實(shí)際產(chǎn)品以及需求而設(shè)置合理的權(quán)限。本文作者通過介紹RBAC權(quán)限模型的概念,結(jié)合實(shí)際案例,對B端產(chǎn)品的權(quán)限設(shè)計(jì)進(jìn)行了分析,一起來看一下吧。
隨著互聯(lián)網(wǎng)的快速發(fā)展,B端行業(yè)也逐漸崛起,很多企業(yè)管理中使用的軟件我們通常稱其為B端管理系統(tǒng),而在B端系統(tǒng)中“權(quán)限管理”是必不可少的功能,不同的系統(tǒng)中權(quán)限的應(yīng)用復(fù)雜程度不一樣,都是根據(jù)實(shí)際產(chǎn)品以及需求情況而設(shè)置合理的權(quán)限。
而我們現(xiàn)在對于權(quán)限的設(shè)置基本上都是建立在RBAC權(quán)限模型上的、擴(kuò)展的,下面我會通過介紹RBAC權(quán)限模型的概念,以及結(jié)合實(shí)際業(yè)務(wù)情況列舉權(quán)限設(shè)置的應(yīng)用。
一、什么是RBAC權(quán)限模型?
RBAC是Role-BasedAccess Control的英文縮寫,意思是基于角色的訪問控制。RBAC認(rèn)為權(quán)限授權(quán)實(shí)際上是Who、What、How的問題。在RBAC模型中,who、what、how構(gòu)成了訪問權(quán)限三元組,也就是“Who對What進(jìn)行How的操作,也就是“主體”對“客體”的操作。其中who是權(quán)限的擁有者或主體(例如:User、Role),what是資源或?qū)ο螅≧esource、Class)。
簡單的理解其理念就是將“角色”這個概念賦予用戶,在系統(tǒng)中用戶與權(quán)限之間通過角色進(jìn)行關(guān)聯(lián),以這樣的方法來實(shí)現(xiàn)靈活配置。
RBAC其實(shí)是一種分析模型,主要分為:基本模型RBAC0、角色分層模型RBAC1、角色限制模型RBAC2和統(tǒng)一模型RBAC3。
RBAC權(quán)限模型是基于角色的權(quán)限控制。模型中有幾個關(guān)鍵的術(shù)語:
- 用戶:系統(tǒng)接口及訪問的操作者
- 權(quán)限:能夠訪問某接口或者做某操作的授權(quán)資格
- 角色:具有一類相同操作權(quán)限的用戶的總稱
1. RBAC0
RBAC0是RBAC權(quán)限模型的核心思想,RBAC1、RBAC2、RBAC3都是在RBAC0上進(jìn)行擴(kuò)展的。RBAC0是由四部分構(gòu)成:用戶、角色、會話、許可。
用戶和角色的含義很簡單,通過字面意思即可明白,會話:指用戶被賦予角色的過程,稱之為會話或者是說激活角色;許可:就是角色擁有的權(quán)限(操作和和被控制的對象),簡單的說就是用戶可使用的功能或者可查看的數(shù)據(jù)。
用戶與角色是多對多的關(guān)系,用戶與會話是一對一的關(guān)系,會話與角色是一對多的關(guān)系,角色與許可是多對多的關(guān)系。
2. RBAC1
RBAC1是在RBAC0權(quán)限模型的基礎(chǔ)上,在角色中加入了繼承的概念,添加了繼承的概念后,角色就有了上下級或者等級關(guān)系。
舉例:集團(tuán)權(quán)責(zé)清單下包含的角色有:系統(tǒng)管理員、總部權(quán)責(zé)管理員、區(qū)域權(quán)責(zé)管理員、普通用戶,當(dāng)管理方式向下兼容時(shí),就可以采用RBAC1的繼承關(guān)系來實(shí)現(xiàn)權(quán)限的設(shè)置。上層角色擁有下層的所有角色的權(quán)限,且上層角色可擁有額外的權(quán)限
3. RBAC2
RBAC2是在RBAC0權(quán)限模型的基礎(chǔ)上,在用戶和角色以及會話和角色之間分別加入了約束的概念(職責(zé)分離),職責(zé)分離指的是同一個人不能擁有兩種特定的權(quán)限(例如財(cái)務(wù)部的納入和支出,或者運(yùn)動員和裁判員等等)。
用戶和角色的約束有以下幾種形式:
- 互斥角色:同一個用戶在兩個互斥角色中只能選擇一個(也會存在一個用戶擁有多個角色情況,但是需要通過切換用戶角色來實(shí)現(xiàn)對不同業(yè)務(wù)操作)
- 基數(shù)約束:一個用戶擁有的角色是有限的,一個角色擁有的許可也是有限的
- 先決條件約束:用戶想要獲得高級角色,首先必須擁有低級角色
會話和角色之間的約束,可以動態(tài)的約束用戶擁有的角色,例如一個用戶可以擁有兩個角色,但是運(yùn)行時(shí)只能激活一個角色。
例如:iconfont和藍(lán)湖的用戶與角色就采用了約束的概念,超級管理員只允許只有一個
4. RBAC3
RBAC3是RBAC1與RBAC2的合集,所以RBAC3包含繼承和約束。
二、為什么要引用RBAC權(quán)限模型?
RBAC中具有角色的概念,如果沒有角色這個概念,那么在系統(tǒng)中,每個用戶都需要單獨(dú)設(shè)置權(quán)限,而系統(tǒng)中所涉及到的功能權(quán)限和數(shù)據(jù)權(quán)限都非常多,每個用戶都單獨(dú)設(shè)置權(quán)限對于維護(hù)權(quán)限的管理員來說無疑是一件繁瑣且工作量巨大的任務(wù)。
而引入角色這個概念后,我們只需要給系統(tǒng)設(shè)置不同的角色,給角色賦予權(quán)限,再將用戶與角色關(guān)聯(lián),這樣用戶所關(guān)聯(lián)的角色就直接擁有了該角色下的所有權(quán)限。
例如:用戶1~用戶8分別擁有以下權(quán)限,不同用戶具有相同權(quán)限的我用不同的顏色做了區(qū)分,如下圖:
在沒有引入RBAC權(quán)限模型的情況下,用戶與權(quán)限的關(guān)系圖可采用下圖的楊叔叔展示,每個用戶分別設(shè)置對應(yīng)的權(quán)限,即便是具有相同權(quán)限的用戶也需要多次設(shè)置權(quán)限。
引入RBAC權(quán)限模型及引入了角色的概念,根據(jù)上面表格的統(tǒng)計(jì),用戶1、用戶3、用戶5、用戶8擁有的權(quán)限相同,用戶2、用戶6、用戶7擁有相同的權(quán)限,用戶4是獨(dú)立的權(quán)限,所以我們這里可以根據(jù)數(shù)據(jù)統(tǒng)計(jì),以及實(shí)際的需求情況,可以建立三個不同的角色,角色A、角色B、角色C,三個角色分別對應(yīng)三組用戶不同的權(quán)限,如下圖所示:
對應(yīng)的上面的案例表格我們就可以調(diào)整為含有角色列的數(shù)據(jù)表,這樣便可以清楚的知道每個用戶所對應(yīng)的角色及權(quán)限。
通過引用RBAC權(quán)限模型后,對于系統(tǒng)中大量的用戶的權(quán)限設(shè)置可以更好的建立管理,角色的引入讓具有相同權(quán)限的用戶可以統(tǒng)一關(guān)聯(lián)到相同的的角色中,這樣只需要在系統(tǒng)中設(shè)置一次角色的權(quán)限,后續(xù)的用戶便可以直接關(guān)聯(lián)這些角色。
這樣就省去了重復(fù)設(shè)置權(quán)限的過程,對于大型平臺的應(yīng)用上,用戶的數(shù)量成千上萬,這樣就可避免在設(shè)置權(quán)限這項(xiàng)工作上浪費(fèi)大量的時(shí)間。
三、引入用戶組的概念
我們依舊拿上面表格案例舉例,雖然前面我們應(yīng)用的RBAC權(quán)限模型的概念,但是對于大量用戶擁有相同權(quán)限的用戶,我們同樣的也需要對每個用戶設(shè)置對應(yīng)的角色,如果一個部門上萬人,那么我們就需要給這個部門上萬人分別設(shè)置角色。
而這上萬其實(shí)是具有相同的權(quán)限的,如果直接采用基礎(chǔ)的RBAC權(quán)限模型的話,那么面對這樣的情況,無疑也是具有一個龐大的重復(fù)的工作量,并且也不利于后期用戶變更的維護(hù)管理,那么針對相同用戶具有相同的權(quán)限的情況,我們便可以引入用戶組的概念。
什么是用戶組呢?用戶組:把具有相同角色的用戶進(jìn)行分類。
上面我們的數(shù)據(jù)表格案例中的用戶1、用戶3、用戶5、用戶8具有相同的角色A,用戶2、用戶6、用戶7也擁有相同的角色B,那么我們就可以將這些具有相同角色的用戶建立用戶組的關(guān)系,拿上面的案例,我們分別對相同角色的用戶建立組關(guān)系,如下:
- 用戶1、用戶3、用戶5、用戶8→建立用戶組1
- 用戶2、用戶6、用戶7→建立用戶組2
因?yàn)橛脩?只有一個用戶,所以直接還是單獨(dú)建立用戶與角色的關(guān)系,不需要建立用戶組,當(dāng)然盡管只有一個用戶也是可以建立用戶組的關(guān)系,這樣有利于后期其他用戶與用于4具有相同的角色時(shí),就可以直接將其他用戶添加到這個用戶組下即可,根據(jù)業(yè)務(wù)的實(shí)際情況而選擇適合的方案即可。
通過案例表格的變化我們就可以直觀的看出權(quán)限設(shè)置變得清晰簡潔了,通過對用戶組賦予角色,可以減少大量的重復(fù)的工作,我們常見的企業(yè)組織、部門下經(jīng)常會出現(xiàn)不同用戶具有相同角色的情況,所以采用用戶組的方式,便可以很好地解決這個問題。
給具有相同權(quán)限的用戶建立用戶組,將用戶組關(guān)聯(lián)到對應(yīng)的角色下,此用戶組就擁有了此角色下的所有權(quán)限,而用戶是屬于用戶組的,所以用戶組下的所有用戶也就同樣的擁有了此角色下的所有權(quán)限。一個用戶可以屬于多個用戶組,一個用戶組也可以包括多個用戶,所以用戶與用戶組是多對多的關(guān)系。
四、引入權(quán)限組的概念
權(quán)限組與用戶組的原理差不多,是將一些相對固定的功能或者權(quán)限建立組的關(guān)系,然后再給此權(quán)限組賦予角色,目前我所接觸的B端項(xiàng)目中使用權(quán)限組的概念的比較少,可簡單地看一下關(guān)系圖:
五、功能權(quán)限和數(shù)據(jù)權(quán)限
B端系統(tǒng)中一般產(chǎn)品的權(quán)限由頁面、操作和數(shù)據(jù)構(gòu)成。頁面與操作相互關(guān)聯(lián),必須擁有頁面權(quán)限,才能分配該頁面下對應(yīng)的操作權(quán)限,數(shù)據(jù)可被增刪改查。所以將權(quán)限管理分為功能權(quán)限管理和數(shù)據(jù)權(quán)限管理。
- 功能權(quán)限管理:指的是用戶可看到那些模塊,能操作那些按鈕,因?yàn)槠髽I(yè)中的用戶擁有不同的角色,擁有的職責(zé)也是不同的。
- 數(shù)據(jù)權(quán)限管理:指的是用戶可看到哪些模塊的哪些數(shù)據(jù)。
例如:一個系統(tǒng)中包含多個權(quán)責(zé)清單(清單1、清單2、清單3),系統(tǒng)管理員能對整個系統(tǒng)操作維護(hù),也就可以對系統(tǒng)中的所有清單都能操作(增、刪、改、查);假如分配給總部權(quán)責(zé)管理員的是清單1,那么他將只能對清單1進(jìn)行操作(增、改、查);普通用戶也許只有查看數(shù)據(jù)的權(quán)限,沒有數(shù)據(jù)操作的權(quán)限(查),這里的操作是系統(tǒng)中所有可點(diǎn)擊的按鈕權(quán)限操作,列舉的增刪改查只是最常見的幾種操作而已。
六、實(shí)戰(zhàn)案例總結(jié)
我目前所做的項(xiàng)目是一個關(guān)于權(quán)責(zé)管理平臺的B端系統(tǒng),關(guān)于系統(tǒng)中的權(quán)限需求我這里簡單的介紹一下,并采用上面所總結(jié)的RBAC權(quán)限模型對實(shí)際業(yè)務(wù)需求進(jìn)行設(shè)計(jì)分析:
- 不同的區(qū)域管理員的權(quán)限各不相同(說明會存在不同的用戶具有不同的權(quán)限,那么我們就可以采用角色對其進(jìn)行規(guī)范)
- 有大量的用戶具有相同的權(quán)限(例如組織、部門等)(說明存在相同權(quán)限的用戶,那么我們就可以采用用戶組的概念)
- 上級管理員擁有下級人員的所有權(quán)限(說明存在繼承關(guān)系)
- 不同用戶所看到的數(shù)據(jù)和能編輯的數(shù)據(jù)不同,一些機(jī)密性的數(shù)據(jù)只允許部分人員看或者編輯(說明存在約束)
- 會存在臨時(shí)性的用戶(說明需要支持新建新角色)
- 同一用戶會存在多個角色(多角色求合集或者切換用戶角色)
簡單說明一下,我所做這個項(xiàng)目的人員管理是在另外一個系統(tǒng)中管理的,權(quán)責(zé)平臺只是調(diào)用另外一個平臺的組織結(jié)構(gòu)樹即可,所以權(quán)限設(shè)置模塊沒有做人員管理的模塊。
根據(jù)上面對需求的分析,整個權(quán)限管理模塊中我們需要建立用戶組管理模塊、功能角色管理模塊、業(yè)務(wù)(數(shù)據(jù))管理模塊、權(quán)限設(shè)置模塊,下面就對每個模塊做更細(xì)致的頁面展示設(shè)計(jì)分析。
1. 用戶組管理模塊
用戶組管理主要是對具有相同權(quán)限的用戶分類建組,所以頁面中我們需要有新建用戶組的功能,每個用戶組下我們需要關(guān)聯(lián)對應(yīng)的組織、部門、崗位、人員,讓這些具有相同權(quán)限的用戶在同一個用戶組下,如下圖:
2. 功能角色管理模塊
B端項(xiàng)目中一般會建立幾個默認(rèn)的角色是不支持用戶修改、刪除的,例如最常見的系統(tǒng)管理員,而也會需要有其它角色的需求,所以此模塊需要支持用戶新建角色,功能角色是對大模塊的頁面和操作的權(quán)限設(shè)置,操作權(quán)限的顆粒度可以細(xì)分到每個頁面的每一個按鈕的操作,如下圖:
3. 業(yè)務(wù)(數(shù)據(jù))角色管理模塊
業(yè)務(wù)角色是對頁面中的數(shù)據(jù)查看的權(quán)限設(shè)置,而對于系統(tǒng)中的普通用戶查看系統(tǒng)的權(quán)限是常用不變的,所以我們考慮默認(rèn)有一個普通用戶的角色,其它業(yè)務(wù)角色用戶根據(jù)實(shí)際需求情況自行建立即可。
由于我們權(quán)責(zé)系統(tǒng)的特殊性,我們需要滿足用戶對部分?jǐn)?shù)據(jù)可編輯且對部分?jǐn)?shù)據(jù)的字段可編輯,按照常理來說,編輯的操作行為是屬于功能權(quán)限的設(shè)置,但是這里的操作行為是建立在數(shù)據(jù)的基礎(chǔ)之上的,所以如果把這里對數(shù)據(jù)的操作權(quán)限在功能角色模塊中設(shè)置,就會顯得混亂。
所以我們直接在業(yè)務(wù)角色模塊中加入對數(shù)據(jù)的可編輯權(quán)限,這里在設(shè)置的時(shí)候更方便靈活。
4. 權(quán)限設(shè)置模塊
權(quán)限設(shè)置模塊只需要設(shè)置權(quán)限分配的對象,選擇對應(yīng)的用戶或者用戶組,關(guān)聯(lián)對應(yīng)的功能角色和業(yè)務(wù)(數(shù)據(jù))角色即可,這樣就形成了一條完整的閉環(huán)的權(quán)限設(shè)置。
對于06同一用戶會存在多個角色,我們系統(tǒng)是采用切換角色的模式來實(shí)現(xiàn)的,因?yàn)椴煌巧写嬖诨コ獾那闆r,以及所涉及的領(lǐng)域不同,操作權(quán)限差距較大,求合集不利于控制權(quán)限,所以只能采用切換的模式實(shí)現(xiàn)。
七、總結(jié)
權(quán)限設(shè)置是B端項(xiàng)目必不可少的模塊,也是令設(shè)計(jì)師頭疼的一件事,但是只要理清楚實(shí)際的業(yè)務(wù)需求,合理運(yùn)用RBAC權(quán)限設(shè)置的原理,其實(shí)也沒那么難,關(guān)于權(quán)限設(shè)置的分享就到這來了,希望對處于B端設(shè)計(jì)的小伙伴有所幫助,也歡迎大家和我一起討論關(guān)于設(shè)計(jì)的有趣事情哦!
本文由 @設(shè)計(jì)小余 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于 CC0 協(xié)議
本文由 @設(shè)計(jì)小余 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于 CC0 協(xié)議
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
管理員屬于業(yè)務(wù)角色中普通用戶的范疇嗎? 還是說在業(yè)務(wù)角色中,不是按照權(quán)限管理角色來區(qū)分的,而是可選擇特定的人群進(jìn)行業(yè)務(wù)數(shù)據(jù)權(quán)限的分配?
這個文章中權(quán)限管理的管理員是屬于業(yè)務(wù)角色中普通的用戶,只是通過權(quán)限管理辣區(qū)分角色的,這是常見的權(quán)限管理模式。但是在三員管理中,管理員就不屬于業(yè)務(wù)角色中普通的用戶,是特定的人群進(jìn)行角色分配管理的,三員管理的功能文章中沒有做總結(jié)
沒必要劃分用戶組,角色就夠了。用角色定義用戶對所有實(shí)例的功能權(quán)限、組織權(quán)限、數(shù)據(jù)權(quán)限(分列表、頁面、字段),再復(fù)雜的還有分享數(shù)據(jù)的權(quán)限管理,包括系統(tǒng)管理員角色對組織、用戶、角色的管理。權(quán)限約束用角色+組織就可以實(shí)現(xiàn)。用戶量大,總部管理員可授權(quán)各級組織的管理員來處理。
另外,通過崗位調(diào)整自動授權(quán)的方式,在多級銷售組織中很容易出錯的,比如部門下的小組,在HR行政組織中是沒有的。要區(qū)分行政組織、業(yè)務(wù)組織、財(cái)務(wù)組織、虛擬組織的。
權(quán)限設(shè)置確實(shí)是有簡單的也有比較復(fù)雜的,不過都需要根據(jù)產(chǎn)品具體需求和應(yīng)用場景去選擇適合的方案,我這里也是根據(jù)自己在工作中所接觸的真實(shí)項(xiàng)目而分享的一種權(quán)限設(shè)置方案哈,大家合理參考
有點(diǎn)沒看明白,既然角色跟用戶組是1V1的關(guān)系,為啥還有用戶組的概念;
新進(jìn)的單個數(shù)據(jù),可以之間配角色,批量導(dǎo)入的數(shù)據(jù)直接在導(dǎo)入表中加入角色的字段不是可以實(shí)現(xiàn)用戶組的概念么…我還是沒想明白,期望有大佬可解答,這個用戶組到底能解決啥場景跟問題
+1,理解下來其實(shí)角色就是用戶組,1角色對應(yīng)同一批組織
角色是系統(tǒng)中設(shè)置的功能角色或者業(yè)務(wù)數(shù)據(jù)角色(功能角色例如:系統(tǒng)管理員、區(qū)域管理員、瀏覽者等等,是對系統(tǒng)中功能做權(quán)限管理的,業(yè)務(wù)數(shù)據(jù)角色是對系統(tǒng)中業(yè)務(wù)數(shù)據(jù)設(shè)置的角色,是針對系統(tǒng)中數(shù)據(jù)做管理的,例如一個權(quán)責(zé)清單,清單中包含數(shù)萬條數(shù)據(jù),不同用戶維護(hù)的數(shù)據(jù)量不同,例如系統(tǒng)管理員可以維護(hù)和查看全量數(shù)據(jù),而區(qū)域管理員只能維護(hù)和查看屬于自己區(qū)域的數(shù)據(jù)。)
用戶組:是對具有相同權(quán)限的用戶創(chuàng)建組的概念,例如:某區(qū)域的多個普通員工具有相同的數(shù)據(jù)和功能權(quán)限,這樣就可以直接將這些普通員工創(chuàng)建用戶組,一次性設(shè)置所有員工的功能角色和業(yè)務(wù)數(shù)據(jù)角色)方便維護(hù)
在實(shí)際業(yè)務(wù)中同樣都是部門主任,他們同一角色,但是職能是不一樣的,就需要劃分a單位主任組,b單位主任組,來分配角色,方便管理,當(dāng)然 也可以直接將這批人分成x角色,但是維護(hù)時(shí)候這個角色下有幾百人,哪些人是一起的一個單位的,都不清楚,比較麻煩。說白了就是把這個角色下的用戶加了個標(biāo)簽分類。
看具體業(yè)務(wù)需求,ERP 系統(tǒng)權(quán)限,比這復(fù)雜多了,,所以沒有標(biāo)準(zhǔn),多余說法,,多去實(shí)踐,跨行業(yè)競品學(xué)習(xí),,
您舉個例子我們學(xué)習(xí)下
確實(shí)真實(shí)的業(yè)務(wù)場景是非常復(fù)雜的,也有在同一張表中,部分?jǐn)?shù)據(jù)具有查閱權(quán)限,部分?jǐn)?shù)據(jù)具有編輯權(quán)限,還有一部分?jǐn)?shù)據(jù)具有新增和、編輯、刪除的權(quán)限,雖然在同一張表格中,數(shù)據(jù)也有不同的權(quán)限
是的,具體場景,具體設(shè)計(jì),不是大而全,搞死人的。
學(xué)多人直覺性點(diǎn)對點(diǎn)不過腦反問,真的需要沉浸式業(yè)務(wù)學(xué)習(xí),體系化了解,
一個角色足矣,沒有必要拆成功能角色和業(yè)務(wù)角色,用戶組也是多余
對于簡單的業(yè)務(wù)一個角色確實(shí)可以,但是針對復(fù)雜的業(yè)務(wù)需求場景還是有必要拆分
一般情況下需要用戶組嗎?目前已遇到這個問題
還是需要清楚你的真實(shí)業(yè)務(wù)需求再選擇是否需要用戶組,如果多人具有相同功能角色和業(yè)務(wù)角色,那么可以考慮用戶組
用戶組的概念還是有點(diǎn)多余
系統(tǒng)用戶幾千人,不同單位,同一崗位角色,這種操作起來如果不分組,那一個角色下面就會出現(xiàn)不同單位的幾百個人,維護(hù)起來費(fèi)事
我覺得產(chǎn)品設(shè)計(jì)過于復(fù)雜了
實(shí)際業(yè)務(wù)場景需要,當(dāng)然常見的簡單權(quán)限設(shè)置也不需要這樣考慮用戶組、功能和數(shù)據(jù)權(quán)限分離的情況
為啥功能角色和業(yè)務(wù)角色不能整合一起呢?出現(xiàn)有A頁面權(quán)限卻無A頁面數(shù)據(jù)權(quán)限如何處理?依據(jù)組織隔離數(shù)據(jù)的場景如何滿足?
具有A頁面的的權(quán)限,一般也是針對該頁面的部分?jǐn)?shù)據(jù)做權(quán)限管理吧,如果單獨(dú)開放該頁面的功能權(quán)限,卻不開放該頁面的數(shù)據(jù)權(quán)限,就會出現(xiàn)空頁的狀態(tài),一般不會這樣分配設(shè)置權(quán)限的,實(shí)際業(yè)務(wù)也比較少見
組織隔離數(shù)據(jù)就會用到用戶組的概念呀
業(yè)務(wù)角色,和功能角色的差異如何理解
業(yè)務(wù)角色也稱數(shù)據(jù)角色,是對系統(tǒng)中數(shù)據(jù)做權(quán)限管理,功能角色是對系統(tǒng)中操作功能(增、刪、改等)的權(quán)限