API change: Let UcAddressesPermissions be able to check access for other users

Problem/Motivation

The UcAddressesPermissions class only can check access for the current active user. This limitation makes it harder to integrate Ubercart Addresses with the Entiy API and specifically with the entity_access() function, because with that function an account object can be passed to check access for. See also #1831424-4: Turn Ubercart Addresses address into an entity.

Proposed resolution

The UcAddressesPermissions class needs to be adjusted, so it can be used to check access for other users as well, instead of the current logged in user only.
The downside of this change is that it could lead to unexpected results for modules that implement hook_uc_addresses_may_view(), hook_uc_addresses_may_edit() or hook_uc_addresses_may_delete().

Remaining tasks

• Adjust the UcAddressesPermission class.
• Modify hook documentation in uc_addresses.api.php.
• Modify hook documentation in the on-line documentation.

User interface changes

None.

API changes

• The UcAddressesPermissions class will accept an additional optional parameter called $account in several methods. If given, access will be checked for that account instead of the current active user.
• For the following hooks an additional parameter called $account will be added:
  • hook_uc_addresses_may_view()
  • hook_uc_addresses_may_edit()
  • hook_uc_addresses_may_delete()

  Modules that implemented these hooks and based these implementations on the current active user will need to adjust their code to avoid unexpected results when access checks are done for other users than the current active one. The "core" features of Ubercart Addresses won't do this, but modules calling entity_access() may do so and probably also the Views address access filters (see #1391216: Views integration for the 6.x-2.x and 7.x-1.x version) will do, once they are implemented.

A patch will follow.