Tried to merge this, but while testing it in production it was just way to slow on main crew list page. There are a lot of access lookups, so no big surprise. I think we can probably improve this in at least a couple of ways:
Go trough any extra database lookups the permission verification process triggers, and if possible remove or cache/pre-calculate parts of them (in crew with x, if admin, if chief, etc)
Reduce the amount of personal details listed on main crew list. It probably makes sense to go to a users profile for full contact information, even if you'r a chief?
In special views which are only available to certain users skip filter completely. Since "access to special view => access to user details"
While trying to add some basic profile picture privacy filters progress was halted since there wasn't a shared location for making sure user privacy preferences where taken into account.
This PR starts to gather the filters and logic we use when viewing user profile data of user Y as user X. For now this mostly matches existing implementations previously spread across different locations. But the idea is that we should extend it with other privacy options as needed, including hiding data of inactive users, users from other events, etc.
Not quite sure how to test ApiController changes, so would be nice if some would verify that part
How it works
Any time you want to get a user object for use in a view (or other possible public facing location):
Get user object as usual
Pass it through $this->Acl->filterPrivateUserDetails($user) (or other way of accessing the ACL Component)
The user object returned has been filtered based on user privacy preferences (such as hiding phone, email, etc) and the permissions of the viewing user (same crew, leader, superuser, etc).
Use returned user as usual, but make sure to check if user properties are !empty (or similar) before accessing and outputing them
Tried to merge this, but while testing it in production it was just way to slow on main crew list page. There are a lot of access lookups, so no big surprise. I think we can probably improve this in at least a couple of ways:
While trying to add some basic profile picture privacy filters progress was halted since there wasn't a shared location for making sure user privacy preferences where taken into account.
This PR starts to gather the filters and logic we use when viewing user profile data of user Y as user X. For now this mostly matches existing implementations previously spread across different locations. But the idea is that we should extend it with other privacy options as needed, including hiding data of inactive users, users from other events, etc.
Relates to: https://github.com/gathering/wannabe/issues/20 Combines with https://github.com/gathering/wannabe/pull/65 to improve image privacy
Not quite sure how to test ApiController changes, so would be nice if some would verify that part
How it works
Any time you want to get a user object for use in a view (or other possible public facing location):
$this->Acl->filterPrivateUserDetails($user)(or other way of accessing the ACL Component)!empty(or similar) before accessing and outputing them