immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-16 05:34:30 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

[PR #24816] feat(mobile): enhance album sorting functionality with order handling #18002

New Issue
Open
opened 2026-02-05 16:30:59 +03:00 by OVERLORD · 0 comments
OVERLORD commented 2026-02-05 16:30:59 +03:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/immich-app/immich/pull/24816
Author: @LeLunZ
Created: 12/24/2025
Status: 🔄 Open

Base: main ← Head: main

📝 Commits (8)

  • 726ebf9 feat: enhance album sorting functionality with effective order handling
  • 672751f mobile: formatting
  • a0d63c8 test: align album sorting order in unit tests with defaultSortOrder
  • 72c88a3 test(mobile): add reverse order validation for album sorting
  • 7f88bef chore(PR): remove OppositeSortOrder Extension and move it directly into SortOrder enum
  • 018ea1a refactor: return sorted list directly in album sorting function
  • b428339 refactor: remove sort_order_extensions.dart
  • 7b4243b Merge remote-tracking branch 'upstream/main'

📊 Changes

5 files changed (+47 additions, -17 deletions)

View changed files

📝 mobile/lib/constants/enums.dart (+8 -1)
📝 mobile/lib/domain/services/remote_album.service.dart (+5 -2)
📝 mobile/lib/presentation/widgets/album/album_selector.widget.dart (+6 -2)
📝 mobile/lib/providers/album/album_sort_by_options.provider.dart (+11 -7)
📝 mobile/test/domain/services/album.service_test.dart (+17 -5)

📄 Description

Description

This PR improves the albums selector sorting logic and its visual representation to better match the behaviour of the web interface and to fix inconsistencies in the current mobile implementation.

Background / Problem

Previously, album sorting implicitly assumed a ascending default order for all sort modes. While this makes sense for modes like "Album Title" or "Oldest Photo", it leads to unintuitive behavior for others such as "Album Size" or "Most Recent".

In addition, there was a bug in the Oldest Photo sort mode:

  • The albums were sorted descending instead of ascending
  • This caused the order indicator to be misleading:
    • Arrow up showed newest → oldest (descending)
    • Arrow down showed oldest → newest (ascending)
  • If you go by the logic, arrow up means ascending. The currently implemented behaviour is not right.

What this PR changes

  • Introduces a defaultOrder for each AlbumSortMode
    • Each sort mode now explicitly defines whether its default order is ascending or descending.
    • This removes the assumption that all modes default to ascending.
    • Switching sort modes now results in a more intuitive initial order that matches the mode’s semantics.
  • Fixes the incorrect order indicator for “Oldest Photo”
    • The order indicator (arrow direction) now correctly reflects the actual sorting.
  • Improves sort order indicator logic
    • Previously, the UI assumed:
      • arrow up = isReverse == false
      • arrow down = isReverse == true
    • The indicator now reflects the effective sort order (asc / desc also in conjunction with the reverse flag) instead of relying on the reverse flag alone.
    • This keeps the UI consistent with the actual sort behavior.
  • Resets reverse ordering when switching sort modes
    • When selecting a different sort mode, the reverse state is set to false.
    • This makes switching modes more predictable for the end user.

Please let me know what you think about these changes :)
I myself don't like reflecting ascending/descending in the up/down arrow. But thats just how it's done in the web and I guess how it makes sense to memorise it.

How Has This Been Tested?

  • Clicking through the UI
  • new test in album.service_test.dart
    • should flip order when isReverse is true for all modes

Checklist:

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation if applicable
  • I have no unrelated changes in the PR.
  • I have confirmed that any new dependencies are strictly necessary.
  • I have written tests for new code (if applicable)
  • I have followed naming conventions/patterns in the surrounding code
  • All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
  • All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

Please describe to which degree, if any, an LLM was used in creating this pull request.

Partly to generate this documentation.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/immich-app/immich/pull/24816 **Author:** [@LeLunZ](https://github.com/LeLunZ) **Created:** 12/24/2025 **Status:** 🔄 Open **Base:** `main` ← **Head:** `main` --- ### 📝 Commits (8) - [`726ebf9`](https://github.com/immich-app/immich/commit/726ebf9ecafe47b0a15669f4a5e48ba3a39399fd) feat: enhance album sorting functionality with effective order handling - [`672751f`](https://github.com/immich-app/immich/commit/672751fb94a65cad085add595a9b1ef340e1ef3d) mobile: formatting - [`a0d63c8`](https://github.com/immich-app/immich/commit/a0d63c87ae0db421150499ee293075eeed5dfe3e) test: align album sorting order in unit tests with defaultSortOrder - [`72c88a3`](https://github.com/immich-app/immich/commit/72c88a31a0d83d727bde62cd2d7659113e688644) test(mobile): add reverse order validation for album sorting - [`7f88bef`](https://github.com/immich-app/immich/commit/7f88bef0f9cefeb8f1922e5190ee0212cf9bafb2) chore(PR): remove OppositeSortOrder Extension and move it directly into SortOrder enum - [`018ea1a`](https://github.com/immich-app/immich/commit/018ea1a62a5689428abcb509d32180d0a8ac2a6f) refactor: return sorted list directly in album sorting function - [`b428339`](https://github.com/immich-app/immich/commit/b42833984e4a439a15eb3b341ee2a7bbfb1b03de) refactor: remove sort_order_extensions.dart - [`7b4243b`](https://github.com/immich-app/immich/commit/7b4243ba04b8b1408c8aca4be2a71b1bfd027ded) Merge remote-tracking branch 'upstream/main' ### 📊 Changes **5 files changed** (+47 additions, -17 deletions) <details> <summary>View changed files</summary> 📝 `mobile/lib/constants/enums.dart` (+8 -1) 📝 `mobile/lib/domain/services/remote_album.service.dart` (+5 -2) 📝 `mobile/lib/presentation/widgets/album/album_selector.widget.dart` (+6 -2) 📝 `mobile/lib/providers/album/album_sort_by_options.provider.dart` (+11 -7) 📝 `mobile/test/domain/services/album.service_test.dart` (+17 -5) </details> ### 📄 Description ## Description This PR improves the albums selector sorting logic and its visual representation to better match the behaviour of the web interface and to fix inconsistencies in the current mobile implementation. **Background / Problem** Previously, album sorting implicitly assumed a ascending default order for all sort modes. While this makes sense for modes like "Album Title" or "Oldest Photo", it leads to unintuitive behavior for others such as "Album Size" or "Most Recent". In addition, there was a bug in the *Oldest Photo* sort mode: - The albums were sorted descending instead of ascending - This caused the order indicator to be misleading: - Arrow up showed *newest → oldest* (descending) - Arrow down showed *oldest → newest* (ascending) - If you go by the logic, arrow up means ascending. The currently implemented behaviour is not right. **What this PR changes** - Introduces a `defaultOrder` for each `AlbumSortMode` - Each sort mode now explicitly defines whether its default order is ascending or descending. - This removes the assumption that all modes default to ascending. - Switching sort modes now results in a more intuitive initial order that matches the mode’s semantics. - Fixes the incorrect order indicator for “Oldest Photo” - The order indicator (arrow direction) now correctly reflects the actual sorting. - Improves sort order indicator logic - Previously, the UI assumed: - arrow up = `isReverse == false` - arrow down = `isReverse == true` - The indicator now reflects the *effective sort order* (`asc` / `desc` also in conjunction with the reverse flag) instead of relying on the reverse flag alone. - This keeps the UI consistent with the actual sort behavior. - Resets reverse ordering when switching sort modes - When selecting a different sort mode, the reverse state is set to false. - This makes switching modes more predictable for the end user. **Please** let me know what you think about these changes :) I myself don't like reflecting ascending/descending in the up/down arrow. But thats just how it's done in the web and I guess how it makes sense to memorise it. ## How Has This Been Tested? - Clicking through the UI - new test in album.service_test.dart - `should flip order when isReverse is true for all modes` ## Checklist: - [X] I have performed a self-review of my own code - [ ] I have made corresponding changes to the documentation if applicable - [X] I have no unrelated changes in the PR. - [X] I have confirmed that any new dependencies are strictly necessary. - [ ] I have written tests for new code (if applicable) - [X] I have followed naming conventions/patterns in the surrounding code - [X] All code in `src/services/` uses repositories implementations for database calls, filesystem operations, etc. - [X] All code in `src/repositories/` is pretty basic/simple and does not have any immich specific logic (that belongs in `src/services/`) ## Please describe to which degree, if any, an LLM was used in creating this pull request. Partly to generate this documentation. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
OVERLORD added the pull-request label 2026-02-05 16:30:59 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#18002
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?