The PK of \Auth\Model\Auth_Userpermission is (user_id, perms_id).
Which are assigned by you when you forge the object. So when it's time to create the record, the ORM will try to create the relation by adding the keys, which it can't, because they are already assigned.
Try removing the 'user_id' assignment from the forge() array.
I've removed the user_id parameter and user has been created successfully, but I faced with one more problem that is very strange for me.
I'm trying to login by the created user and get an exception Fuel\Core\PhpErrorException [ Warning ]: array_intersect_key(): Argument #1 is not an array PKGPATH/auth/classes/auth/acl/ormacl.php @ line 189
I've debug this call and got following result -------------------------------------------------------------------- File ormacl:186, array_intersect_key function call.
The first parameter is returned as a string (serialized array): $user->userpermission['['.$user->id.']['.$permission->id.']']->permission->actions
An argument for the second parameter is returned as an array: $user->group->grouppermission['['.$user->group_id.']['.$permission->id.']']->actions
F.e., in my case the are: a:1:{i:0;s:6:"action";}Array ( [0] => 0 )
When I do unserialize of the first parameter then I'm able to perform login.
The Auth models use the Observer_Typing to automatically serialize/unserialize the action arrays. This has been in there since day one, so why in your case it isn't unserialized I don't know.
I can't reproduce it here, so I don't know what goes wrong. Are you on 1.8/develop? If not, it might be worthwhile to switch to the latest develop code for the Auth package, flush all your cache, and see if you still have it.
Really, when I've moved to 1.8/dev unserialization become normal.
Harro, I'm appreciate very much your time you spend for me , but let me please to make more exact one question:
Is a record with "actions" equal NULL in "users_user_permissions" absolutely wrong and doesn't have any sense or it is appropriate when we don't want to check any concrete actions but an area and a permission only?
The actions column in the join table act like a filter.
So on the permission record you define all possible actions for that permission, say array(0 => 'A', 1 => 'B", 2 => 'C").
Then in the action of the join record (in this example between a user and a permission, you can define array(0,1) to only asign A and B to that user, but not C.
If you don't put anything in the action (either NULL or an empty array), the user still has that permission (so has_access('area.permission') will return true), but none of the actions assigned.
@Harro [citation] If you don't put anything in the action (either NULL or an empty array), the user still has that permission (so has_access('area.permission') will return true), but none of the actions assigned. [/citation]
I thought so too but if I'm trying to perform following check: Auth::has_access('etude.view'); I get an Exception ***************** Fuel\Core\PhpErrorException [ Warning ]: array_flip() expects parameter 1 to be array, null given PKGPATH/auth/classes/auth/acl/ormacl.php @ line 187 *****************
There is code at the line: array_flip($user->userpermission['['.$user->id.']['.$permission->id.']']->actions)
I've update core, orm and auth to 1.8/dev
P.S.: May be some database info will be useful
A record in the users_permissions table: 1 | area | perm | descr | "s:23:""a:1:{i:0;s:6:""action"";}"";" | 2 | 1382813094 | 0
A record in the users_user_permissions table: 15 | 1 | NULL
On all action columns, the Orm Typing observer is active to automatically serialize on save, and unserialize on read. I checked the code, and it will convert a NULL value to array(), so I'm very curious to see why that doesn't happen in your case.
However, I can reproduce this here, so I'll have a look.
Donate
