liferay許可權作用
liferay中使用的許可權管理系統的內部細節，涉及到資料庫表以及實體之間的管理和許可權管理的邏輯。
所有涉及到的實體關係
主要實體
首先從表或者本人更喜歡稱作實體的表開始，換言之，他們界定的實體定義了關於許可權和角色的東東。
User_：用戶
最明顯主要的一個實體就是“用戶”（Users）了。關於許可權的一個總是被提及的問題是："Does this user have permission to do this action on this thing?" ，用戶就是執行某些操作完成某些任務的人。
Organization_：組織
用戶只能夠屬於一個組織（Organization）或一個地區（Location）。這裡使用了一個相同的數據模型表示Organzation和Location。基本上如果
列parentOrganizationId的值是-1，則表示一個Organization，否則就是一個Location。在邏輯上一個Location的父必須是一個Organization。
用戶（Users）能夠繼承所屬Organization或Location的許可權（permissions/roles）
UserGroup:用戶組
用戶可以屬於一個或多個的用戶組，用戶組僅僅是一堆用戶的集合，不屬於任何公司、任何組織、任何地區，僅僅只是為了方便分配角色或許可權，而將具有共性（比如：具有相同的崗位或職務等）的一些用戶進行分組。，用戶能夠從用戶組繼承許可權（permissions/roles）。當前parentUserGroupId列未使用。
Group_:組
組Group）現在稱作社區（Communities），用戶可以屬於一個或多個的社區，並且能夠集成所屬社區的許可權和角色。注意在Group_表中，存在一個className和classPk列。如果某條記錄的這兩個列的值為空，則該條記錄指的是一個社區。如果className的值是com.liferay.portal.model.User，則該條記錄為一個私有的用戶社區（只允許Power Users）.如果className 的值是 com.liferay.portal.model.Organization，則這條記錄表示了一個組織（Organization）或地區（Location）如果className 的值是 com.liferay.portal.model.UserGroup則表示這條記錄記錄的是一個UserGroup（用戶組）。可以說：組（Group）是Organization和Location已經UserGroup的集合。
存在組（Group）用於記錄Organizations/Locations 和UserGroups的原因在於：這樣可以簡化其他實體（比如許可權（permissions）和角色（role））同用戶（Users）之間的關係。
許可權和角色（Permissions and Roles）
好，現在讓我們看看這些表是怎樣和許可權關聯起來的，首先我們要看一下“許可權”（permission）是如何定義的，簡單地說，許可權就是在資源（RESOURCE）上的操作（ACTION）。許可權能夠被直接授予用戶（USER）或通過不同的方式被繼承。角色是許可權的集合。讓我們從“Resource_”表開始
Resource_ 表:
Resource_ 一個資源可以是在prtal中代表一個對象的，你要在上施加許可權的任何東西。可以是一個portlet，一個社區（community），一個用戶（User），一個訊息公告,一個Blog實體...任何都可以。讓我們先快速瀏覽一下Resource_表格的各個列：
* resourceId = 資源的標識
* companyId = 資源所屬的公司ID
* name = 資源對象的描述，如果資源描述的是一個portlet對象，則為這個portlet對象的portletId.如果是一個class, 則為帶包名的class全名稱。
* typeId = 在當前，只是用來描述classes的許可權，因此該列的值總是"class". 然而,在將來, 也許回用來描述files或Folders授權,因此 typeId 的值可能會是 "file" or "folder".
* scope = 這裡可能的值是"company" (指 企業級"Enterprise Scope"), "group" (指 社區級"Community Scope"), or "individual" (指私人級"Individual Scope"). Why the different naming conventions? Because things change... The numeric values for scope (as found in the database) can be found in the class com.liferay.portal.model.impl.ResourceImpl
Permission_ 表
如前所述，許可權（permission）是在資源上施加的操作，因此Permission_表有actionId和resourceId這兩個列，像預料的一樣，這裡的resourceId列引用Resource_表的resourceId列。然而，actionId列不存在對應的Action_表，所有的actionId定義在ActionKeys類中。如何在資源上定義一個新的操作？可以閱讀許可權的實現代碼。
Role_ 表，這個表定義了角色，實際上，這裡只有一個主要的列是“name”，這是因為角色（roles）必須有一個獨一無二的名稱。
Roles_Permissions 角色-許可權表
這是連線許可權和角色的關係表，沒有這裡的連線，角色就沒有用了...他們僅是一下空的容器。
分配用戶到社區和組織（communities and organizations）
Users_Groups 表：是用戶（User）和社區（Community）的關係表。你也許感到困惑，為什莫這裡沒有className和classPK列在這張表中，
這樣的話我們就能夠處理所有的實體（例如社區Communites, 組織Organization/地區Locations, 用戶組UserGroups）。這很難解釋...(原文就是這樣：...too hard to explain, but trust us...it's better this way.)
Users_Orgs 用戶-組織表
連線用戶 User 到一個組織（Organization）/地區（Location.）的關係表
Users_UserGroups
連線用戶 User 到一個用戶組（UserGroup）的關係表
分配角色和許可權
Users_Permissions 用戶-許可權 表
直接連線一個許可權（Permission）到用戶（User）的關係表.
Users_Roles 用戶-角色 表
連線角色（Role）到用戶（User）的關係表，用戶有所屬角色的所有許可權（通過Roles_Permissions）
Groups_Permissions 組-許可權 表
連線一個許可權permission 到一個組 Group的關係表.還記得在前面提到過，一個Group_記錄能夠表示社區（Community），組織（Organization）/地區（Location）或是用戶組（UserGroup）嗎？好，通過這個表可以之間關聯到所有這些實體，當然屬於這些實體的用戶能夠繼承他們的許可權，需要注意的是，沒有Orgs_Permissions 或 UserGroups_Permissions 表。Groups_Permissions足夠處理這些事情，因此才是現在看起來比較簡單
Groups_Roles 組-角色 表
連線角色（role）到組（Group）的關係表，像Groups_Permissions一樣，組（Group）可以是社區、組織/地區或用戶組（UserGroup）,用戶能夠繼承這些“組（Group）”對應的角色許可權。
Groups_Orgs 組-組織 表
是連線組織（Organization）/地區（Location）的關係表，換言之，一個管理員（admin）能夠分配任何組織或地區的所屬用戶到一個社區。
結果是：分配給社區的任何許可權或角色能夠被在組織或地區中選擇的用戶繼承。
Groups_UserGroups 組-用戶組
實際上像Groups_Orgs一樣。只是針對UserGroup而已。
OrgGroupPermission 這個表在代碼沒有被使用到，實際上被用作“排除許可權”，基本上來說，一個用戶必須屬於一個特定的地區（或組織，從liferay4.4開始）和一個特定的社區（Community）。雖然該表存在，但是在代碼中並沒有使用。
可以通過一個例子了解為什麼這個選項是有用的，在一個社區（Community）中假設有一個留言板，管理員想要設定某一類的留言板能夠給地區（Location）的用戶留言，一次他點擊“Permission”圖示，選取了特定的地區（Location），現在所有的屬於這個Location的用戶都能夠留言了，而不管他們是否屬於這個社區。
在另外的場景下，管理員想要進行更多的限制，用戶必須屬於指定的組織才能發表留言，他就可以通過設定“排除許可權”來完成。
