Search (and therefore tag search / Tags page) ignores access_permissions — only checks ownership and public link access

[scientific-method-course]

Lychee version

7.10.0

Did you check the latest Lychee version?

Yes, I did

Which PHP version are you using?

PHP 8.5

Detailed description of the problem

Photos/albums shared with a specific user or user group (via access_permissions.user_id / user_group_id) are correctly visible when browsing directly to the shared album, but are not returned by search — including tag search (tag: modifier) and the Tags overview page, which appears to use the same underlying search path.

The step-by-step diagnosis I made myself. Claude.ai helped my track down the possible cause. I share its analysis below.

Root cause (traced in source):
PhotoSearch::sqlQuery() → PhotoQueryPolicy::applySearchabilityFilter() → appendSearchabilityConditions() → AlbumQueryPolicy::appendUnreachableAlbumsCondition().
In appendUnreachableAlbumsCondition() (app/Policies/AlbumQueryPolicy.php), an album is only treated as reachable if:
the user is the album's owner (inner_base_albums.owner_id = $user_id), or
it's accessible via the public link/password mechanism (is_link_required, password, unlocked_album_ids).
The method never checks access_permissions.user_id or access_permissions.user_group_id — i.e. it never looks at explicit per-user or per-group shares at all, even though the same computed_access_permissions join is already present in the query (used only for the link/password check).
This is inconsistent with the browsability path (applyBrowsabilityFilter), which does correctly honor these shares — that's why direct navigation to a shared album works, but search does not.
Expected behavior: Photos in albums shared via access_permissions (user or group) should be included in search results and the Tags page, consistent with their browsability.
Suggested fix area: AlbumQueryPolicy::appendUnreachableAlbumsCondition() — extend the reachability condition to also treat an album as reachable when a matching row exists in access_permissions for the current user (directly, or via user_group_id for a group the user belongs to).

Steps to reproduce the issue

1. As admin, share an album with another (non-owner) user — either directly (per-user share) or via a User Group — granting at least view access.
2. Log in as that user.
3. Confirm the shared album and its photos are browsable directly (works correctly).
4. Try searching by tag (tag:xxx) for a photo known to be in the shared album, or visit the Tags page.
5. Observe: no results / empty Tags page, even though the same photo's tags are visible on its own detail page.

I tested this both by directly sharing an album with a user, and by sharing it with a group of which the regular user is a member. I propagated the permissions from the top level album and checked that they were applied to the album with tagged photos. I gave the regular user, with which I shared, all permissions possible (to rule out that the tag searching was somehow related to a specific permission).

Diagnostics [REQUIRED]

Info
Lychee SE Version (release): 7.10.0
DB Version: 7.10.0
Docker: lycheeorg-frankenphp
composer install: --no-dev
APP_ENV: production
APP_DEBUG: false
APP_URL: set
APP_DIR: default
LOG_VIEWER_ENABLED: false
System: Linux
PHP Version: 8.5.11
PHP User agent: Lychee/6 (https://lycheeorg.dev/)
int size 64 bits 8
Timezone: Europe/Amsterdam
Max uploaded file size: 128M
Max post size: 128M
Chunk size: 102.40 MB
Max execution time: 30
MySQL Version: 11.8.9-MariaDB-ubu2404
exec() Available: yes
Imagick Available: 1
Imagick Enabled: yes
Imagick Version: 1809
GD Version: bundled (2.1.0 compatible)
Number of foreign key: 55 found.

Browser & System [REQUIRED]

Firefox on Android 15

Please confirm (incomplete submissions will not be addressed)

• I have provided easy and step-by-step instructions to reproduce the bug.
• I understand my bug report will be removed if I haven't met the criteria above.
• I understand that if I am requested to provide more information, I must do so within 14 days or the bug report will be closed.

[ildyria]

That is a good point.
I recently did some change in this direction (which should be in edge): #4827
May I trouble you to re-run your tests?

But I agree that this needs to be fixed.

[scientific-method-course]

Thanks for your extremely fast response. I could rerun my tests, but I guess I then should do it per your instructions? Or you mean, once a new version is available? 3 okt 2026 17:13:35 Benoît Viguier ***@***.***>:

…

That is a good point. I recently did some change in this direction (which should be in *edge*): #4827[#4827] May I trouble you to re-run your tests? But I agree that this needs to be fixed. — Reply to this email directly, view it on GitHub[#4832?email_source=notifications&email_token=AM3SIWFFZ7OO53DYYCHW72T5SEJRRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGMZDEMRSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18732222], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AM3SIWGEVFLHQI4LASJADVT5SEJRRAVCNFSNUABIKJSXA33TNF2G64TZHMYTIMZZG42TQMBUHNCGS43DOVZXG2LPNY5TCMBZGQZTIMZXUF3AE]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS[https://github.com/notifications/mobile/ios/AM3SIWEU4SLAJQMEQ4G3Z7D5SEJRRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGMZDEMRSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM] and Android[https://github.com/notifications/mobile/android/AM3SIWFB5FXXEEFF24BLBR35SEJRRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGMZDEMRSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE]. Download it today! You are receiving this because you authored the thread. [Tracking-afbeelding][https://github.com/notifications/beacon/AM3SIWAQKNO32LIMDWAGNVT5SEJRRBFCNFSM6AAAAADBD6XI22WGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQBDXKL5JTSMVQXG33OUZQXK5DIN5ZA.gif]

[ildyria]

Nevermind, given your example I should be able to reproduce it.

[scientific-method-course]

I did some further testing today. I discovered that the 'search by tag' issue for the user with which the album is shared is not a permission issue (I think).

• for the user that owned the albums I now also ran into zero results for often-used tags.
• then I started to search for tags that are less frequent, and for the owner of the album tag search yielded results again
• then I changed the PHP timeout and bigger searches worked as well.
• then I went back to the Admin settings in search of a setting on pagination of search results. It turned out that 'Maximum number of photo results returned by a single search.' does exactly do that (initially I thought it simply truncated search results).
• then I went back to the shared - with - user. And now searches by tag worked.

The page linked to the 'tags' menu item is still empty though (to me that is less problematic than if my family members would not be able to search by tag).

Thanks for tthe good work, Arnold