數據管理權限學習生活筆記我們經常在數據權限中找不到正確的方法。如何在后臺設計數據許可框架，以滿足我們的業務需求？作者從三個方面給出了關于數據權威的知識，讓我們一起來看一下。看到了這樣的要求：他想知道，我“為什么”可以看到這個數據？如果我自己創建了這些數據，其他人看到的原因是什么？我的第一反應是數據權限的設計太復雜了。隨后又想到：“為什么進行數據管理權限要設計的這么一個復雜呢，有沒有更好的實現中國方案？”但是在你回答這個問題之前，還有一件事你可能要先做，那就是弄清楚什么是數據權限？需要數據訪問支持的業務場景是什么？簡單地說，數據訪問就是“用戶是否可以查看數據”，主要是出于業務信息安全方面的考慮，不同的人，在不同的情況下，數據的范圍可以不同。為了方便編寫，將使用“查看數據”來統一描述數據。其實數據權限有很多類型，比如添加\\u002刪除\\u002fchanging\\u002fsarching\\u002植絨\\u002Funlocking\\共享，本文就不介紹了。本文將結合在工作中遇見的一些企業業務應用場景，跟大家可以分享自己一些比較常見的數據進行權限設計，也希望學生能夠總結出一套，最符合本公司業務的數據權限架構體系。一、基礎數據權限對象級權限基礎數據權限通常會承載到一個權限媒介上，比如說權限集，職能等。他通常包括兩部分，對象級權限與字段級權限。簡單地說，對象級權限控制用戶是否可以看到業務菜單或業務選項卡，這意味著用戶甚至不知道系統中存在這種類型的數據。對象級權限的設計包括以下內容。當然，對于不同的企業，可能會有更細致的管理，比如數據傳輸、鎖定\\u002Funlocking等基礎功能都可以而且需要控制。關于“查詢自己所有數據關聯”和“修改所有企業關聯”，他的權限優先級是要高于世界其他管理權限規則。比如商機、訂單、報價單等業務發展對象都關聯了客戶，那么我們如果在客戶上設置了“查詢系統所有關聯”的話，就會覆蓋掉具體分析關聯業務服務實體可以設置的對象級權限。字段級權限根據企業業務發展需要，即使我們可以通過看到某個公司業務研究對象，但也需要對某些隱私字段做數據管理權限處理。例如：聯系人電話、薪水等信息，不會對所有人開放。如果企業系統包含頁面布局設置，則字段級別的權限，以覆蓋布局設置。二、記錄級數據權限其實對于很多業務系統來說，可能上面的基礎數據權限設計已經能夠滿足大部分數據權限場景了，但問題是有一類“特殊場景”解決不了。只有“一部分”人才能獲得的“一部分”數據。幾乎所有復雜的數據進行權限設計，都是為了自己解決中國這個社會問題，而且也是因為他們使用場景差異太大，很難找到一個一攬子解決方案。所以發展需要具有多種方案結合，才能在便捷性、安全性上，滿足中大部分企業環境復雜的數據權限要求。系統默認權限要想得到解決某“一部分”數據，只允許“一部分”人操作，理論上那就不是意味著每一條信息數據我們都應該學習可以被控制。那么每一個學生用戶與每一條數據發展之間進行到底是什么關系，是業務管理系統設計需要回答的第一個問題。通常來講，系統默認權限應該是“最嚴格的”，“唯一”的“限制”數據權限的方式，其他的記錄級數據權限，應該是在系統默認權限的基礎上，增加額外的數據權限。例如，最極端的限制是，所有的業務數據都是不可見的。當然，對于一些公司來說，有些數據是完全可見的，比如公告、地址簿、社區帖子和其他類型的數據。如果系統默認權限需要修改，則需要通過嚴格的控制流進行管理。畢竟這是整個數據權限框架中唯一的限制。記錄所屬人通常我們來說，如果沒有一個企業用戶可以擁有某個業務發展實體創建對象的權限，那么針對這條特定的記錄，用戶通過創建工作完成數據記錄后，會自動變為這條記錄的所屬人（owner）。在系統默認權限的基礎上，記錄的所屬人就屬于一種新增的數據權限，可以對這個用戶進行查看操作（可進行的操作應該基于基礎數據權限）。由于業務的需要，記錄會在不同的用戶之間進行數據轉移的操作（transferownership），所以記錄所屬人，不一定是記錄的創建人。另一個例外是記錄不屬于特定用戶。在有些企業公司的業務中，會有一個類似公海池、隊列等記錄分配器進行功能。這些記錄也可能屬于這些分配者，在他們被分配之前。相關函數的成員可以在列表視圖中查看這些分配器中的記錄數據，并執行所有者-索賠操作（更多細節將在隨后的公海池設計中更新）。部門/相關部門每個企業的組織結構都會分為部門，所以有一個很自然的需求場景:看到這個部門和下屬部門相關的所有數據。一種通過比較可以簡單的做法，就是在創建一個數據的時候，自動將數據進行關聯到創建網絡用戶的所屬部門上。還有一些情況，有些公司的數據是由專門的團隊負責創建的，那么針對于這些數據，就需要可以變更數據的所屬部門的能力。隨著業務持續增長，可能需要跨部門的數據視圖，即根據數據權限設置一個主要部門和多個相關部門的用戶。直屬負責人/助理在傳統的組織結構中，除了部門層級之間的數據共享要求外，還存在人員匯報關系。通常的做法，就是我們在為每一個學生用戶，指定一個國家直屬上級部門負責人，直屬上級負責人會被時代賦予所有下屬層級的相同信息數據權限。為了企業管理可以方便，也可以為直屬負責人進行設置助理，助理與直屬負責人具備基本相同的數據權限，這樣更靈活的讓不同的用戶之間能夠跳脫出公司社會組織系統架構的束縛。崗位層級使用部門授權制度的問題在于，企業的組織結構常常與企業的不一致。業務體系結構經常更改，結構更改可能是數據訪問控制的一個挑戰。崗位層級，可以根據數據權限需要，將一個用戶或者一組用戶放在同樣的崗位下。這樣的話，在創建工作崗位的同時，也可以進行很好的了解企業公司管理架構到底應該以什么樣的形式組織生活在一起更高效。你可以從上到下設置工作層次，比如，最高職位叫做ceo你可以查看整個組織的數據。然后由業務部總經理或負責區域的職位，繼續細分下來，看看各職位下的數據。作業級權威更強大的功能之一是作業可以與數據有m:n關系，這意味著同一塊數據可以同時被多個作業共享，從而允許更復雜的數據共享場景。職位級別的設計可以將數據與用戶解綁，便于人員變動、業務調整時的數據共享變更。共享規則對于企業數據進行權限管理還有一類可以更加接近直覺的設計教學方式，也就是別搞那些花里胡哨的概念，我就是我們要把“這一重要部分”數據，共享給“那一部分”人，簡單問題直接一點，怎么做？換句話來講，如果上面的權限設計管理體系統統不能滿足企業業務場景，可不可以通過提供一種直接的數據信息共享發展方式。“共享規則”的設計研究方案可能是一種可以解決問題思路。通常來講，共享規則進行解決了兩類場景：與特定用戶共享特定用戶的數據。把符合中國特定環境條件的數據，共享給特定用戶。當然這里面的“特定用戶”，不僅僅只用戶本身，所有包含用戶的容器概念元素（部門、群組、角色等），應該都包含在內。手工共享共享規則很方便，但它們解決不了更致命的數據權限場景。有些共享場景是不可預測的，隨機的，隨時隨地的。怎么辦？事實上，這個場景的前提條件決定了權限設計的方式。由于規則不起作用，您可以手動指定它們。手工共享的數據進行權限管理設計，完全是一種基于記錄所屬人的自由意志，記錄所屬人認為這些數據我們應該通過共享給誰，就共享給誰好了。需要注意的是，當記錄的所屬關系發生變更時，那么手工共享關系應該直接解除。記錄所屬人也需要可以隨時查看和修改，當前這條數據的手工共享情況。團隊成員手工共享確實解決了使用非標準化規則的數據權限場景，但問題是，隨著記錄所有者的所有權轉移，共享關系將丟失。作為記錄，如果大多數需要共享的用戶不經常更改，您可以嘗試由團隊成員手動共享。記錄所屬人或者有記錄編輯權限的團隊成員，可以通過同時添加一些其他企業用戶管理作為中國這條記錄的團隊成員，記錄會對我們所有團隊成員共享。這樣即使記錄所屬人發生變化，其他的團隊成員會仍然保留與此條記錄的數據共享關系。除了支持用戶之外，團隊成員還需要支持部門，團隊可以更靈活地支持單片數據的共享。群組共享團隊成員共享方案，能夠有效解決問題大部分企業需要進行靈活配置的單條數據資源共享場景，但操作比較繁瑣。如果我們需要進行頻繁共享給一個網絡虛擬經濟組織管理團隊，就需要在每一條數據上添加若干個，相同的團隊成員，效率很低。群組就會很好地解決這個問題，若幾個用戶之間需要經常共享數據，那么可以將用戶們用群組圈起來，記錄的所屬人，可以通過將自己創建的、符合條件的數據，自動共享到若干群組中，用戶也可以通過手動共享的方式，將某條數據共享到群組中。只有組成員可以看到組中的數據，組通常分為公共組和私有組。公共組是整個公司都可以看到的組，任何人都可以與公共組共享數據。私用群組是每個人都是獨立進行創建的，只有群組成員之間可以將數據信息共享到私用群組中。群組應該是我們可以通過支持嵌套結構關系的，比如：用戶、角色、崗位、群組企業本身，都是可以是一個群組的一員。當然處于性能的考慮，最好對類似群組套群組的這種方式，做一個層級上的限制。群組與數據的關系應該是多對多的，也就是說，同樣一條數據，可以在不同的群組中做共享。群組數據的共享應該是獨立的，通過類似于其他工作層次，直接上級相關的其他權限，無法突破群組成員的限制。這意味著usera是一個組的成員，可以看到組的數據，但是usera的老板不能看到組的數據，因為他不是組的成員。區域層級對于一個大型公司企業發展應用場景，經常會出現銷售、產品、服務分屬于自己不同的業務單元，但需要我們根據學生不同的規則共享客戶等相關數據資源。那么這樣就可以創建多個區域層級，讓同一個客戶可以按照不同的層級結構共享給各個方面不同的業務單元。與作業層次結構類似，區域層次結構通過區域、客戶層次、行業、產品線等不同的區域維度規則，通常應用于站點資源管理的數據權限劃分。在創建/編輯相應的數據之后，可以自動將其輸入到符合規則的區域中。通過學習一些級聯跟隨社會分配的設置，數據下的相關信息數據也可以發展同時我們進入到一個相同區域，比如客戶下的訂單，訂單下的回款單等。數據進入到區域后，區域成員就可以看到數據了。一般來講，區域權限分為2級，Object、Hirerachy。Object業務發展對象級權限，說的是一個重要區域社會成員針對于具體的業務研究對象，是什么權限。比如針對于客戶，是查看自己還是可以編輯?領導層的權威是，對于一個企業實體來說，除了當地的權威之外，它是否還擁有當地的權威。對于單個區域，如果有業務需要，還可以添加Record級別的權限，類似于記錄的所有者。針對于每一個中國區域，也可以通過設置這個目標區域的記錄企業負責人(TerritoryRecordOwner)，這樣學生對于一個基于不同區域經濟管理的業務進行屬性來講，可以將記錄做到最靈活的配置。三、如何應用數據權限回到最初提到的問題，他們的深層考慮是什么？如果我們這條數據是我自己可以創建的，那么對于其他能看到這條數據時代的人都有誰？對于很多企業來講，從數據隱私安全的角度考慮到數據權限問題，是很重要的命題。對數據進行權限因果鏈條的掌握，可以對整個系統數據管理權限控制體系的優化，起到至關重要的指導教師作用。”小王已經從甲部調過來了，他可以通過助手的特權見到乙部的客戶。我們應該立即取消小王的特權“小張是C事業部的銷售成員，通過群組權限看到他本應看到的客戶，而不是崗位權限看到這個客戶，看來客戶的分配邏輯有一些問題。”有人想知道，為什么我會看到這些數據？當用戶能夠看到這條數據時，通過我們看到這條數據的原因，可以進行快速的找準學生自己的職責定位。因為我是客戶團隊的一員，我需要投入精力培養客戶。這個企業客戶是我下屬自拓的一名新客戶，那么我需要對其給予我們幫助。更重要的是，經常的審視數據進行權限管理體系的因果關系，也會對業務發展本身認識得更清晰，優秀的數據權限體系，甚至我們可以通過優化設計公司的業務運營服務體系，讓效率不斷提升自下而上的發生。所以問題是，既然一個好的數據訪問系統可以提高管理效率，那么有沒有可以遵循的設計原則呢？還是作為一個公司的業務運營經理，到底該如何設計公司的數據訪問系統？在我們可以設計權限體系的時候，都是用各種相關概念將具體的權限，通過不斷滿足特定業務場景的方式進行包裝發展起來。我們把包裝發展起來的這樣學生一個個的概念，可以通過稱之為“權限進行媒介”。有三種類型的允許媒體：（1）Owner獨立媒介，比如記錄所屬人，崗位層級。可以自主的滿足所有的權限結構；還可以包括其他許可系統。（2）Child亞媒體，例如團體、地區。可以自主的滿足所有的權限結構；可以被特定的Owner媒介技術包含；還可以包括其他許可系統。3.Element原子媒介，例如助理/直接主管，從屬于部門一級。可以理解為一種內部權威媒介；僅可以通過包含一些其他原子媒介。權限媒介的自身屬性類型可以幫助我們認識到，權限體系的設計是整體的，而不是混亂的。一旦一個媒介被定義為一個元素，那么就沒有屬性所有者。這也許能解決一段時間的問題，但是擴張會很困難。權限媒介在使用不同場景上，分為以下兩種類型:（1）有規則的比如共享規則，崗位層級。根據公司的