我的项目需求是这样的:
在顶部,将有管理员,他将拥有所有 d 访问权限,第一级
在管理员下,将有部门主管,他将拥有所有 d 访问权限,除了
在部门负责人下创建部门负责人之外,还有其他成员,他们将管理分配给他们的部门明智数据。
现在,所有不同的部门负责人都将拥有自己的信息和成员,并且所有部门负责人/成员都将有权访问他们自己正在输入/管理的特定记录。
现在,使用 CakePHP 的 ACL 组件,我可以划分角色及其访问级别,但所有部门负责人都可以看到其他部门负责人的信息,因为他们将具有相同的访问级别,并且所有其他成员可以在差异上看到其他成员信息部门,从那时起他们将具有相同级别的访问权限。
我的项目复杂性是 - 尽管他们与其他人具有相同的级别/角色分配,但他们应该仅对他们分配或创建的信息/数据可见。
任何人都可以建议我最合适的选择,使用 CakePHP 现有的插件来管理所有这些事情。
我可以通过自定义默认 ACL 组件来工作,但这将花费比预期更多的时间。
任何更好的想法/建议将不胜感激!
My project requirement is something like this:
On Top, there will be Administrator, who will have all d access, first level
Under Administrator, there will be Department Heads, who will have all d access, apart from Creating Department Heads
Under Department Head, there will Other Members, who will be managing their allocated department wise data.
Now, all different department heads will have their own information and members, and all department heads / Members will have access to their own specific records, which they are entering / managing.
Now, with CakePHP's ACL Component, I can divide the roles and their access level, but all department heads can see the other department head's information, as they will have same level of access, and All Other Members can see the other members information on diff departments, as of they will have same level of access.
My project complexity is that - they should be visible only their assigned or created information / data, though they have same level / role assignments as of others.
Can anyone suggest me best suitable option, to manage all these things with already available plug-ins with CakePHP.
I can work by customizing the default ACL Component, but that will take some more amount of time, than what is expected.
Any better ideas / suggestions would be appreciated !
发布评论
评论(1)
在我看来,ACL 并没有那么神奇。例如:ACL 可以管理权限来告诉谁有权添加/编辑/删除产品。但它无法更改查询以根据定义的权限过滤产品(例如“部门 A 的用户只能查看 A 部门的产品”).. 实际上这是一个谎言,ACL 可以管理它,但可能不切实际,因为每次添加产品时,您都必须创建 ACO,并在 AROS_ACOS 表中设置权限自从AROS 是一个树结构,所以它很容易成为一个噩梦,如果你计划查询你的数据,
我会使用 仅限组的 ACL 来控制对某些页面/操作的访问,并制定如下规则:
“产品列表”及添加/删除/修改
产品”
所有页面"
“产品列表”,他们可以添加
产品,但不删除它们”
,我会根据连接的用户调整我的查询,因此在“产品列表”页面的控制器中,我会执行以下操作:
如果您有太多查询并且不想执行数千个 if 语句,您可以创建一个组件、一个行为或者也许扩展
app_model
中的 find()
方法的想法是捕获所有查询并检查。如果查询中使用的模型之一具有名为“department_id”的字段,如果有,则将model.department_id=connected_user.department_id
条件添加到查询中,我为一个可以的网站执行了此操作 。以多种语言显示,每种语言都有自己的用户、数据、日志等,并且有一个管理员可以查看所有信息.. 这对我来说非常有用 =)
祝你好运!
编辑:
我使用的行为是:
这实际上非常简单,我更改查询以添加一个条件来匹配当前语言($_SESSION['lang'])。在控制器中,我需要做的就是附加 LocalizedBehavior 并像往常一样使用 find 方法:
the way i see it, ACL is not that magical. For exemple: ACL could manage the permissions to tell who has access to add/edit/remove a product.. but it wont be able to change a query to filter the products accordingly to the defined permissions (like "users from department A can only see products from department A").. well actually that's a lie, ACL could manage that but it might not be practical, because every time you add a product you'd have to create an ACO, and set the permission in the AROS_ACOS table and since the AROS is a tree structure, so it could easily become a nigthmare, if your planning to query your data
I'd use a group-only ACL to control the access to certain pages/actions and make rules like:
'products list' and add/delete/modify
products"
all pages"
'products list' and they can add
products but not delete them"
and i'd adjust my queries accordingly to the connected user, so in the controller of 'products list' page, i'd do something like:
product.department_id=connected_user.department_id
if you have too much queries and you dont want to do thousands of if's sentences, you could create a component, a behavior or maybe extend the
find()
method in theapp_model
. The idea is to catch all queries and check if one of the models used on the query have field called "department_id", if they do then add themodel.department_id=connected_user.department_id
condition to the query.I did that for one website that can be seen in multiple languages and each language has it's own users, data, logs, etc., and there's one Admin that can see all the info.. and it's working great for me =)
Good Luck!
EDITED:
the behavior i use is:
it's quite simple really, i change the query to add a condition to match to the current language ($_SESSION['lang']). In the controller all i need to do is to attach the LocalizableBehavior and use find method as usual: