許可權設計問題

使用了rbac模式設計許可權，現在有種情況。
普通a使用者發表一個文章,
a擁有對這個文章的編輯，刪除，查看許可權。
普通b使用者，擁有查看許可權
小編c使用者，擁有對這個文章的編輯，刪除，查看許可權。
編輯，刪除，查看許可權都有對應的按鈕，有許可權就顯示，沒有就不顯示。
應該怎麼設計呢？
例如，編輯按鈕對應的是一個按鈕，動作節點設計成一個，節點的功能有對自己的主題編輯，對他人的主題編輯。

回複內容：

使用了rbac模式設計許可權，現在有種情況。
普通a使用者發表一個文章,
a擁有對這個文章的編輯，刪除，查看許可權。
普通b使用者，擁有查看許可權
小編c使用者，擁有對這個文章的編輯，刪除，查看許可權。
編輯，刪除，查看許可權都有對應的按鈕，有許可權就顯示，沒有就不顯示。
應該怎麼設計呢？
例如，編輯按鈕對應的是一個按鈕，動作節點設計成一個，節點的功能有對自己的主題編輯，對他人的主題編輯。

通常對自己的資料進行編輯、刪除是不需要進行許可權管理的。因為一般來說網站是劃分前背景，普通使用者在前台操作時幾乎不用考慮許可權問題，是誰的誰就能管理。
詳細解釋起來很麻煩，你先思考一下，我覺得你主要是陷入誤區了。

我這樣解釋一下：
已 “編輯主題” 和 “編輯我的主題” 為例 用真值表的方式類比如下：
有 編輯主題 許可權 ， 有 “編輯我的主題” 許可權： T
有 編輯主題 許可權 ， 無 “編輯我的主題” 許可權： T
無 編輯主題 許可權 ， 有 “編輯我的主題” 許可權： 做isAuth檢查並返回 isAuth檢查結果
無 編輯主題 許可權 ， 無 “編輯我的主題” 許可權： F

那麼現在取消 編輯我的主題 使用權限設定，用isAuth檢查代替，真值表為相同結果：
有 編輯主題 許可權 ， isAuth = T： T
有 編輯主題 許可權 ， isAuth = F： T
無 編輯主題 許可權 ， isAuth = T： T
無 編輯主題 許可權 ， isAuth = F: F

你肯定說了，有的地方就算是使用者通過 isAuth 檢查也不讓他用，此類操作不做isAuth檢查不就行了嗎？

class Controller {    protected $_allowIfIsAuth = false;    public function afterDispatch() {        if (! $user->hasPermission('permission_name')) {            if (! ($this->_allowIfIsAuth && $user->isAuth('auth_id'))) {                return false;            }        }        return true;    }}

CREATE TABLE `app_user` (  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵',  `gmt_create` datetime NOT NULL COMMENT '資料新增時間',  `creator` varchar(128) NOT NULL DEFAULT '0' COMMENT '建立者',  `gmt_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '資料修改時間',  `modifier` varchar(128) NOT NULL DEFAULT '0' COMMENT '修改者',  `is_deleted` char(1) NOT NULL DEFAULT 'n' COMMENT '是否邏輯刪除，預設為n',  `ha_id` varchar(64) DEFAULT NULL COMMENT '會員統一ID',  `buc_id` varchar(64) DEFAULT NULL COMMENT '員工統一ID',  `work_no` varchar(64) DEFAULT NULL COMMENT '工號',  `status` varchar(32) DEFAULT NULL COMMENT '狀態',  `user_type` varchar(32) DEFAULT NULL COMMENT '使用者類型',  `user_name` varchar(128) DEFAULT NULL COMMENT '使用者名稱稱',  `email` varchar(64) DEFAULT NULL COMMENT 'E-mail',  `mobile` varchar(32) DEFAULT NULL COMMENT '手機',  `phone` varchar(32) DEFAULT NULL COMMENT '電話',  `home_page_url` varchar(128) DEFAULT NULL COMMENT '首頁URL',  `user_no` varchar(128) DEFAULT NULL COMMENT '使用者編號',  `login_id` varchar(128) DEFAULT NULL COMMENT '登入ID',  PRIMARY KEY (`id`),  KEY `idx_workno` (`work_no`,`is_deleted`),  KEY `login_id` (`login_id`)) ENGINE=InnoDB AUTO_INCREMENT=1774 DEFAULT CHARSET=utf8 COMMENT='系統使用者';CREATE TABLE `app_role` (  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵',  `gmt_create` datetime NOT NULL COMMENT '資料新增時間',  `creator` varchar(128) NOT NULL DEFAULT '0' COMMENT '建立者',  `gmt_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '資料修改時間',  `modifier` varchar(128) NOT NULL DEFAULT '0' COMMENT '修改者',  `is_deleted` char(1) NOT NULL DEFAULT 'n' COMMENT '是否邏輯刪除，預設為n',  `role_name` varchar(64) DEFAULT NULL COMMENT '角色名稱',  `role_type` varchar(32) DEFAULT NULL COMMENT '角色類型',  `home_page_url` varchar(128) DEFAULT NULL COMMENT '首頁URL',  PRIMARY KEY (`id`),  KEY `idx_rolename` (`role_name`,`is_deleted`)) ENGINE=InnoDB AUTO_INCREMENT=1065 DEFAULT CHARSET=utf8 COMMENT='系統角色';CREATE TABLE `app_role_org_user` (  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵',  `gmt_create` datetime NOT NULL COMMENT '資料新增時間',  `creator` varchar(128) NOT NULL DEFAULT '0' COMMENT '建立者',  `gmt_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '資料修改時間',  `modifier` varchar(128) NOT NULL DEFAULT '0' COMMENT '修改者',  `is_deleted` char(1) NOT NULL DEFAULT 'n' COMMENT '是否邏輯刪除，預設為n',  `role_id` bigint(20) DEFAULT NULL COMMENT '角色ID',  `org_id` bigint(20) DEFAULT NULL COMMENT '組織ID',  `user_id` bigint(20) DEFAULT NULL COMMENT '使用者ID',  `home_page_url` varchar(500) DEFAULT NULL COMMENT '首頁URL',  `access_org_path` varchar(256) DEFAULT NULL COMMENT '授權組織路徑',  PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=18658 DEFAULT CHARSET=utf8 COMMENT='系統使用者組織角色';

存一個全域常量標識使用者，並分使用者組分配不同的功能，具體可以看一下one think的思路one think

