Permission system improvements and new permission keys

[yagiz-dev]

System improvements

• Decoupled hide_permissions and can_always_access. Previously, setting either of them would grant automatic full access to the module that couldn't be disabled at all.
  • What should have been was that can_always_access would be used to grant everyone access but hide_permissions should only be used to hide permissions for modules like Branding where you don't actually have anything to guard.
• Implemented per-request caching for staff permissions

New Twig function

• Created a new has_permission Twig function so we can safely leave out parts of the UI that the user isn't authenticated for.
  • This allows us to hide tabs/parts of the UI dynamically
  • Also allows us not to make calls to the API where the user doesn't have access to, so we don't end up getting a full-page exception that prevents rendering anything

{% if has_permission('client', 'create') %} {# Check for a permission key #}
{% if has_permission('client') %} {# Check for module access #}

New permission keys

Created ~25 new permission keys. I think the Client and System ones are especially beneficial to control granular access.

• Client
  • create
  • edit_profile
  • impersonate_login
  • manage_api_keys
  • change_password
  • manage_balance
  • view_login_history
  • manage_groups
  • delete
  • bulk_delete
  • export
• System
  • update_params
  • recheck_update
  • toggle_error_reporting
• Currency
  • create
  • edit
  • delete
  • set_default
  • update_rates
• Redirect
  • create_and_edit
  • delete
• Hook
  • manage_hooks
  • trigger_hooks

[admdly]

Removing hide_permissions => true and adding explicit manage_hooks/trigger_hooks permissions creates a breaking change for existing installations.

All staff members could access hooks since permissions were hidden; now they need explicit grants. Non-admin staff will lose hook access until an admin grants these new permission keys. Maybe this is intentional? Should we not document the change or migrate existing permissions?

[yagiz-dev]

Removing hide_permissions => true and adding explicit manage_hooks/trigger_hooks permissions creates a breaking change for existing installations.

It's intentional. It wasn't hidden behind a permission key like before, just like every other permission key introduced with this PR.

In theory they should just lose view access and the ability to manually trigger hooks via API. Which can be easily reinstated if wanted.

I don't think this disables hooks entirely for the user, but we should check and verify that in any case.

[admdly]

LGTM - incorporated some small corrections (as I know you're busy) and agreed code to get this ready to merge.