壹、對老系統部分功能合並到新系統的疑問
疑問1：存在“部門表”和“部門字典信息”，同時新融入的“用戶組”的概念，這3者肯定有重復。現在系統中用的比較多的是“負責人”選擇“用戶名”或“負責部門”。其中的部門就是“用戶組麽”？回歸到起點：即“用戶組”和”部門”是壹個概念麽？
疑問2：壹個部門或用戶組肯定存在“等級”的概念：“經理”和“普通員工”。所以我認為此處的“等級”就是角色的概念。“角色”可能是需要的。
疑問3：用戶組表和權限表之間存在關系。那麽systemlogin中存在的“User_Right”就不會再起作用了，存在就會矛盾了（暫時存在只是維持老系統不出錯），是不是該刪除User_Right？
總結：理不清他們的具體的關系，以及他們存在的重復性。
二、個人理解的人員、用戶組、權限、角色、菜單之間的關系
說明：
1. 教師A可能屬於“語文組”，也可能屬於“地理組”。
2.“語文組”肯定會有“語文組組長”和“普通教師”壹職，這就是“角色”。其中“語文組組長”可能只有壹個人，但是“語文組普通教師”可能有多人：如教師A、教師B。（細粒度控制）。
3.“語文組”有多種權限，“語文組組長”有權限看“教師A”的提交的工作報告，也有權限看“教師B”提交的工作報告，以及批閱報告。“語文組普通教師”只能查看自己的工作報告，和批改學生的作文等操作。（細粒度控制）
總結：權限往往是壹個極其復雜的問題，但也可簡單表述為這樣的邏輯表達式：
判斷 “Who對What(Which)進行How的操作” 的邏輯表達式是否為真。
三、設計的原則
粗粒度 ：表示類別級，即僅考慮對象的類別(the type of object)，不考慮對象的某個特定實例。比如，用戶管理中，創建、刪除，對所有的用戶都壹視同仁，並不區分操作的具體對象實例。?
細粒度 ：表示實例級，即需要考慮具體對象的實例(the instance of object)，當然，細粒度是在考慮粗粒度的對象類別之後才再考慮特定實例。比如，合同管理中，列表、刪除，需要區分該合同實例是否為當前用戶所創建。
設計原則歸結為：“系統只提供粗粒度的權限，細粒度的權限被認為是業務邏輯的職責”。
需要再次強調的是，這裏表述的權限系統僅是壹個“不完全”的權限系統，即，它不提供所有關於權限的問題的解決方法。它提供壹個基礎，並解決那些具有“***性”的(或者說粗粒度的)部分。在這個基礎之上，根據“業務邏輯”的獨特權限需求，編碼實現剩余部分(或者說細粒度的)部分，才算完整。回到權限的問題公式，通用的設計僅解決了Who+What+How 的問題，其他的權限問題留給業務邏輯解決。
舉例：
人員--------------（所屬用戶組---角色）--------------對應的權限：說明
人員1-----------（組1-------------組長）---------------權限：批閱該組普通組員的報告。
人員1-----------（組2-------------組員）---------------權限：寫報告。查看自己的報告。
人員2-----------（組1-------------組員）---------------權限：寫報告。查看自己的報告。
人員3-----------（組1-------------組員）---------------權限：寫報告。查看自己的報告。
人員4-----------（組2-------------組長）---------------權限：批閱該組普通組員的報告。