Skip to content

refactor: translation bar access check respect user settings for tran… - #2423

Open
sawyerb-ksu wants to merge 2 commits into
artefactual:qa/2.xfrom
sawyerb-ksu:fix-translationbar
Open

sawyerb-ksu wants to merge 2 commits into
artefactual:qa/2.xfrom
sawyerb-ksu:fix-translationbar

Conversation

@sawyerb-ksu

Copy link
Copy Markdown
Contributor

Fix: translation banner shows for admins without explicit translate access

Summary

The "Translate user interface" footer banner was visible to any user whose ACL check passed via a blanket "all privileges" grant (e.g., administrators with the default all-access grant), even when they had never been explicitly granted the translate permission. This made the banner appear for users whose language settings do not actually authorize interface translation.

This change introduces a dedicated access check that requires an explicit translate permission and respects the permission's language conditional, so the banner is only shown to users who have been intentionally granted translate access.

Problem

_footer.php rendered the sfTranslatePlugin banner whenever:

QubitAcl::check('userInterface', 'translate')

QubitAcl::check() also matches blanket acl_permission rows with NULL action ("all privileges"), so administrators with the standard admin grant saw the banner even without an explicit translate grant.

Changes

lib/QubitTranslateBarAccess.class.php (new)

New static helper class with:

  • hasExplicitTranslateAccess(?myUser $user = null): bool — returns true only if the current user has an explicit translate permission (action = 'translate') granted to them directly, to one of their groups (including group ancestors), with a NULL object_id (system-wide), grantDeny = 1, and the permission's language conditional (if any) evaluates true for the user's current UI culture.
  • getExplicitTranslatePermissions(myUser $user): array — protected helper that fetches the matching explicit permission rows, mirroring the role hierarchy built in QubitAcl::buildUserRoleList (authenticated role, user id, user groups, and group ancestors).

apps/qubit/templates/_footer.php

Banner render condition changed from:

if (QubitAcl::check('userInterface', 'translate')) {

to:

if (QubitTranslateBarAccess::hasExplicitTranslateAccess()) {

test/functional/qubit/translationBarCheck.php (new)

Functional test script (runnable inside the test container via php -d xdebug.mode=off test/functional/qubit/translationBarCheck.php, exits 0/1) that drives an in-process sfBrowser and asserts on the #l10n-client footer bar for four scenarios:

# Scenario Expected bar
1 Anonymous visitor (control) absent
2 Admin-group user with blanket "all" grant only absent
3 Same user + explicit translate grant (en), culture en present
4 Same user, UI culture switched to fr (en-only grant) absent

The script creates and cleans up its own test user, group membership, and permission rows. Note: because this fork authenticates via CAS, the test signs the user in by seeding the browser's session file with the same data myUser::signIn() produces, rather than POSTing to /user/login.

Verification

  • Scenario 2 was the failure case before this change (admin with only the blanket grant saw the banner); it now correctly returns no banner.
  • Scenarios 3–4 confirm that explicit grants still work and that the language conditional continues to be enforced (an en-only grant does not show the bar under an fr UI culture).

Risk / Backwards compatibility

  • Users with an explicit translate grant (the normal "can translate" checkbox on a user record) see the banner exactly as before.
  • Users who previously saw the banner only through a blanket "all" grant will no longer see it — this is the intended fix. If such users need the banner, grant the translate permission explicitly.
  • No schema changes, no public API changes beyond the new QubitTranslateBarAccess class.

@sarah-mason sarah-mason added the Community Pull requests that have been contributed from community members outside Artefactual label Sep 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Community Pull requests that have been contributed from community members outside Artefactual

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants