to be honest i haven't used or updated this behavior is quite awhile. i am not sure if those todo's are ever going to get done (at least by me), since i've moved on and have become very busy at work.
as far as how a record owner sets permissions for others is exactly as i pointed out. either you grant more broad permissions to "other", or else you manage non-owner's permissions via groups. meaning, you can create a group that has more permissions for that particular record and then add a user into it. the behavior doesn't know how to do those things, since they are very application/situation specific. that sort of thing is up to you, in how you implement your app. your app would leverage the functionality that currently present, specifically updating the record in question with a new set of bits (that were calculated by the app) if you wanted to change the owner, group or permission bits. if you want to get a better understanding of how this works, find some more in-depth information about how unix groups work. don't focus too hard on the permission bits, but more on how the groups on unix work. a person has a primary group, as well as secondary group memberships. as permissions can be granted to a group on a record (or file/ directory, in unix), there are several ways to implement the type of control set up you are describing. but the most important thing is to understand that, so this behavior's capabilities (or limitations) make more sense. On Sep 28, 11:36 pm, sathyashrayan <sathyashra...@gmail.com> wrote: > On Sep 28, 8:20 pm, jmcneese <jmcne...@gmail.com> wrote: > > > > > > > > > > > hi there. it looks to me that you are not using the groups correctly, > > which is how you restrict non-owner users from undesired actions. the > > bits are just like unix permission bits, in that there is there is a > > user and group id associated with the record, then bits assigned to > > the owner, group and "others" (anyone who is not the owner or in the > > group specified). > > > a practical example would be something like this: > > > you create a new record. that permission record gets automatically > > created with an owner id matching the creating user's id, and a group > > id matching the creating users *primary* group id. the permission > > bits for this new record will either be the default bits defined in > > the behavior configuration, or else whatever you specify in the data > > to be saved. > > > let's say you have two groups, Editors and Authors. you would want > > editors to have full read write access, as well as the creating > > author, but everyone else can only view. that would mean you want to > > have a permission bit of 500 (owner: read/write/delete, group: read/ > > write, others: read). the owner id is the author user's id who > > created the record, and the group id is the editor group's id. > > > this would allow the original author to have full control, editors can > > modify the record but not delete, and all other users can read the > > record but not modify/delete. > > > does that make more sense? > > Hi, > First of all my thanks to the wonderful behavior and reply. I > understood the bit masking part. If you see my previous posts i have > mentioned how the 9 bits works. I am clear about that. But where i > need help is when a record owner wants to assign permission to another > set of groups or users or a single group or user for CRUD on all his > inserted record (data) how can he do that? I am planning for an > interface where the record owner allows permission for his inserted > record to a selected group or users. More than that, you have > mentioned in your TODO list as > > "I intend on updating the plugin to have more options for > configuration, to whit: implementing some level of inheritable > permissions, introducing the concept of roles, supporting “trickle- > down” permission changes to models that actAs Tree, common UNIX-y > commands like chmod/chown/chgrp." > > Please explain more on this points. Though I am a beginner in cakephp > (just 2 months) I could try those TODO for my knowledge gain. > > > > > > > > > > > On Sep 28, 5:41 am, sathyashrayan <sathyashra...@gmail.com> wrote: > > > > On Sep 28, 12:25 pm, sathyashrayan <sathyashra...@gmail.com> wrote: > > > > > On Sep 28, 11:39 am, sathyashrayan <sathyashra...@gmail.com> wrote: > > > > > > Ok I have made the RMAC work > > > > > (http://jmcneese.wordpress.com/2010/01/28/ > > > > > rmac-is-dead-long-live-rmac/) I will tell what i have done. > > > > > > 1)Downloaded a fresh cakephp > > > > > 2)created the users,groups tables > > > > > 3)acos,aros,acos_aros ("cake schema create DbAcl" in command line) > > > > > 4)Baked users and used Auth component to set up a login page > > > > > 5)Placed the plugin in [path]/app/plugin/permissionable > > > > > 6)Created the permission_bits table > > > > > 7)Created a "contacts" table for a sample module > > > > > 8)In the file [path]\app\plugins\permissionable\controllers\components > > > > > \permissionable.php I added > > > > > var $components = array('Session', 'Auth'); > > > > > for calling > > > > > $users = $this->Auth->user(); > > > > > Then assigned userid and groupid in > > > > > > $users = $this->Auth->user(); > > > > > $userId = $users['User']['id']; > > > > > $groupId = $users['User']['id']; > > > > > Permissionable::setUserId($userId); > > > > > Permissionable::setGroupId($groupId); > > > > > Permissionable::setGroupIds(array($groupId)); > > > > > > 9)Created some groups in tree (tree component) with hierarchy > > > > > > 10)Now each user logged in and creates a contact the > > > > > "permission_bits" table gets filled with model,and model Id and 416 > > > > > (default bits) in perms.. > > > > > > 11)If each user logs in and he can see only his records. He can edit > > > > > and view but he can not delete his own record. If an Admin logs in he > > > > > can do all the action(delete also) on all the record including his > > > > > record.. > > > > > > Now what i need is.. > > > > > > 1)Record created user (owner) can also delete his record > > > > > Ok i have found out doing this point. Which is 480 in the prems coloum > > > > of permission_bits table. > > > > 840 == (111) - (100) - (000). Add the line before calling save ($this- > > > > > >Contact->save($this->data)) in the contact_controller.. > > > > > $this->data['Permissionable'] = array('perms'=>480); > > > > > > 2)Record created user (owner) can allow other group's user below his > > > > > level to do all the action (create/update/delete/view) > > > > > > I can guess that this could be done in the Behavior (\app\plugins > > > > > \permissionable\models\behaviors\permissionable.php) with correct bit > > > > > set in the callback functions. But i dont know what is the bit mask > > > > > for that. If i am wrong then please correct me and guide me how to do > > > > > that. > > > > ok I got a bit more closer in this. I have changed the > > > > Permissionable::setUserId(array($userId,6,7)); in the file > > > > [path]\app\plugins\permissionable\controllers\components > > > \permissionable.php > > > > where 6,7 are other user IDs I get the following query generated with > > > beforeFind() callback function from the file [path]\app\plugins > > > \permissionable\models\behaviors\permissionable.php > > > > SELECT `Contact`.*, `ContactPermissionBit`.* FROM `contacts` AS > > > `Contact` INNER JOIN `permission_bits` AS `ContactPermissionBit` ON > > > (`ContactPermissionBit`.`foreign_id` = `Contact`.`id` AND > > > `ContactPermissionBit`.`model` = 'Contact' AND > > > `ContactPermissionBit`.`foreign_id` = `Contact`.`id` AND > > > ((`ContactPermissionBit`.`perms`&4 <> 0) OR > > > (((`ContactPermissionBit`.`perms`&32 <> 0) AND > > > (`ContactPermissionBit`.`gid` = 2))) OR > > > (((`ContactPermissionBit`.`perms`&256 <> 0) AND > > > (`ContactPermissionBit`.`uid` IN (2,6,7)))))) WHERE 1 = 1 LIMIT 20 > > > > Look at the last part of the query IN (2,6,7) that happens with the > > > array of user ids. But this will affect the afterSave() callback in > > > [path]\app\plugins\permissionable\models\behaviors\permissionable.php > > > since it expects a variable but not an array. So I have changed the > > > code to check if its a array or variable. Just added these lines on > > > the top. > > > > //$user_id = Permissionable::getUserId(); > > > //$group_id = Permissionable::getGroupId(); > > > > if(is_array(Permissionable::getUserId())) > > > { > > > $ids_user = Permissionable::getUserId(); > > > $user_id = $ids_user[0]; > > > } > > > else > > > { > > > $user_id = Permissionable::getUserId(); > > > } > > > > if(is_array(Permissionable::getGroupId())) > > > { > > > $ids_group = Permissionable::getGroupId(); > > > $group_id = $ids_group[0]; > > > } > > > else > > > { > > > $group_id = Permissionable::getGroupId(); > > > } > > > > So now this works on both afterSave() and beforeFind() callback > > > function, never minding if it is a array or variable. > > > Now if user id 2 is the leader and user id 6 and 7 are under the > > > privilege of user 2. How can i restrict some resource for the other > > > users such as no deleting possible for 6,7 but only view. But user id > > > 2 could do all the CRUD since he is the master for this record? I > > > think I need to make a bitmask for this in perms but where in > > > afterSave() and what is that bit? > > > > I wounder why I am not getting any help for this issue.. May be people > > > here did not able to open the link which is > > > >http://jmcneese.wordpress.com/2010/01/28/rmac-is-dead-long-live-rmac/... > > > > Please help..:o > > > > > > One more this is when a admin delets all the record the > > > > > "permission_bits" table not getting deleted.. > > > > > > Thanks for any help.. > > > > > > On Sep 26, 5:04 pm, sathyashrayan <sathyashra...@gmail.com> wrote: > > > > > > > Dear group, > > > > > > After i used ACL plugin by Alaxos > > > > > > (http://www.alaxos.ch/blaxos/pages/ > > > > > > view/plugin_acl) i wanted to have a ACL at each record level. That > > > > > > is, > > > > > > a user's record need not be shown to the non-Creator. I started to > > > > > > understand the concept of record level ACL from this thread. > > > > > > > http://groups.google.com/group/cake-php/browse_frm/thread/886fe37ecbc... > > > > > > > After downloading those code from those given links about RMAC i > > > > > > tried to implement it. But I am stuck. So i started to read that > > > > > > code > > > > > > (behaviour, [path]/app/plugin/permissionable/models/behaviors) i > > > > > > understood that its the callback function that does all. Especially > > > > > > the bit checking in _getPermissionQuery function. But I am still not > > > > > > clear in implementation(user end). So i studied the Auth and ACL > > > > > > component in core cake (libs) and i saw the _create,_delete (CRUD) > > > > > > permission is set in Auth. Then I understood that RMAC > > > > > > implementation > > > > > > is different from Core ACL which uses aros_acos table. My doubt with > > > > > > the RMAC plugin is this.. Does every record will have an extra entry > > > > > > in the permission table? Can anyone give an example of this full > > > > > > working of the > > ... > > read more » -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
