"Or user field" privilages are overwriting Details view privileges!

[rostamiani]

Hi
I have a lot of records. each member should have privilege to view details of his own records. I can do this with "Or user field" option.
But I have a super admin too that should have access to view details of all records. When I set "Details view" to "Special" admin cannot access details!

"Or user field" overrides default privileges. How can I change this behavior?

Thanks

 

[troester]

I can't replicate.

List access edit records = special + or use field = userelement is working as expected (users without "special" can see all records, can edit his own record, superadmin can edit all).

Not sure what you mean with "Details view", element settings? Details view is always readonly view.

 

[rostamiani]

Thanks

This is the access tab of one of elements. I set access like this and now Administrator cannot see this element in details view!
When I remove "Or use field" admin grants permission!
Is this a bug?

 

[cheesegrits]

OK, I can confirm this.

The canView() methods was working slightly differently to canEdit(), such that the user access was overriding the group access. I've modified it to work the same ...

https://github.com/Fabrik/fabrik/commit/24c5c521f57539906b27d8eb0b404a758ab0179c

So now canEdit() won't bother checking the user ACL if the group permission is true.

-- hugh

 

[rostamiani]

OK, I can confirm this.

The canView() methods was working slightly differently to canEdit(), such that the user access was overriding the group access. I've modified it to work the same ...

https://github.com/Fabrik/fabrik/commit/24c5c521f57539906b27d8eb0b404a758ab0179c

So now canEdit() won't bother checking the user ACL if the group permission is true.

-- hugh

Thanks a lot...
How can I apply this change to my website? Is it enough to overwrite element.php?

 

[cheesegrits]

We don't recommend "cherry picking" changes in github, as there could be other changes that depend on changes in other files - it depends on how old the code you have installed is.

It's always best to do a full github update (see the wiki).

-- hugh

 

[rostamiani]

We don't recommend "cherry picking" changes in github, as there could be other changes that depend on changes in other files - it depends on how old the code you have installed is.

It's always best to do a full github update (see the wiki).

-- hugh

I applied the change.Before the change user access was overriding group access and now group access is overriding user access. Isn't it a good idea to have both group and user accesses.
What I need is granting access to all Special users plus one single user with the id specified.

Can I do this with editng this line?

// If no group access, can override with check on lookup element's value = logged in user id.
if (!$this->access->$key && $params->get('view_access_user', '') !== '' && $view == 'form')

 

[cheesegrits]

The way access controls work for access levels (not groups) and user is, if the access level ACL doesn't provide access, Fabrik will check to see if the user access does.

So it should now work as you described, "granting access to all Special users plus one single user with the id specified.."

If they are in a group which is in the Special access level, they will get access, and Fabrik won't check the user permissions. If they aren't in Special, so group access is not granted, Fabrik will check to see if the user has access (so the logged on user ID matches the id in the element specified on that row of the form).

-- hugh

 

[rostamiani]

The way access controls work for access levels (not groups) and user is, if the access level ACL doesn't provide access, Fabrik will check to see if the user access does.

So it should now work as you described, "granting access to all Special users plus one single user with the id specified.."

If they are in a group which is in the Special access level, they will get access, and Fabrik won't check the user permissions. If they aren't in Special, so group access is not granted, Fabrik will check to see if the user has access (so the logged on user ID matches the id in the element specified on that row of the form).

-- hugh

But now just Specials group grants access and the field is hidden to the user!
I applied your change by changing that particular line in element.php

 

[cheesegrits]

Ah, a little bug ...

https://github.com/Fabrik/fabrik/commit/887866a2e4870762d7bcb4f24459fd143198bdac

-- hugh

 

[rostamiani]

Ah, a little bug ...

https://github.com/Fabrik/fabrik/commit/887866a2e4870762d7bcb4f24459fd143198bdac

-- hugh

Thanks for your brilliant support...
The problem solved