Session::set_flash('success', 'Deleted group #'.$id);
}
I expect this would both delete the group, and delete it's associated children - such as assigned permissions in the 'users_group_permissions' table
What I actually see is that the group is removed, and the associated permissions in the previously mentioned table just get updated to remove the 'group_id' - set to 0
Is this expected behaviour?
I've tried:
foreach($group->grouppermission as $assigned_permission){
$assigned_permission->delete();
}
$group->delete(true);
Group and permissions are removed but ORM tries to run an insert and errors:
Fuel\Core\Database_Exception [ 1048 ]:
Column 'group_id' cannot be null [ INSERT INTO `users_group_permissions` (`group_id`, `perms_id`, `actions`) VALUES (null, '10', 'a:1:{i:0;s:1:\"0\";}') ]
There is a many-many relation between group and permission, meaning the same permission can be assigned to multiple groups (or users for that matter). So deleting a group should not delete the permission.
If I look in the Auth_Group model, I see it also has a direct relation to that table, to be able to update the actions related to the group-permission combo, which are stored in "users_group_permissions". And that relation has "cascade_delete = false" defined on it. So that might block the delete.
I've looked in the history, it's been there since day 1, april 2013. I'm a bit puzzled as to why it is there. Also to the why we've never bumped into it, I don't know, everyone of our apps uses Auth. A quick peek in the code reveals it uses the same code as you do.
I think It should however delete the junction records in "users_group_permissions" when you delete a group, it is imho pointless to keep them when the group is gone.
Can you check if removing that "cascade_delete" in the Auth_Group doesn't have any side-effects, I'm not in a position to test at the moment...