Add the option to filter lists by status

[doluk]

Thanks for the amazing project. I really enjoy to use it. In the lack of genre labels (like sci-fi for example covering multiple media types) I created a sci-fi list and just added my items to it. But then I run into the issue, that I would only want to see planned items on my sci-fi list....

This pr aims to add filtering by status to the users list similar to how the medialist has it as an option. This is my first time working with Django, so any feedback is appreciated and please excuse any beginner mistakes I made.

I added also a test for it. While working on the tests, I moved the duplicated Movie, etc creation into the setUp function. I just noticed, that I accidentally commited my change to the source of the test items. While someone could argue, that is better to test without the metadata api requests, I am happy to revert the change (from a clean branch, so it isn't in the commit history).

Copilot summary

This pull request introduces a new feature that allows users to filter items in a custom list by their status (e.g., Completed, In Progress, Planning, etc.) in the list detail view. The changes span backend logic, frontend UI, and database schema to support status-based filtering and user preference persistence.

Key changes include:

Backend: Status Filtering and Persistence

• Added a new list_detail_status field to the User model and database, with choices for all relevant statuses and a migration to enforce data integrity. This allows each user to persist their preferred status filter for list detail views. [1] [2] [3]
• Updated the list_detail view in lists/views.py to accept a status parameter, apply filtering by status across all media types, and pass the current status and available choices to the template context. [1] [2] [3] [4]

Frontend: UI for Status Filtering

• Enhanced the list detail template (list_detail.html) to add a status filter dropdown alongside the media type filter, update the Alpine.js state, and ensure the status filter is included in form submissions and HTMX requests. [1] [2] [3]

Testing: Test Refactoring and Coverage

• Refactored tests in test_views.py to create media instances in setUp instead of each test, and added/updated tests to verify status filtering logic and UI. [1] [2] [3] [4] [5] [6]

These changes together provide a robust, user-friendly way to filter list items by status, and ensure the feature is well-tested and persists user preferences.

---

Backend: Status Filtering and Persistence

• Added a list_detail_status field to the User model with choices and a migration, along with a database constraint to ensure valid values. [1] [2] [3]
• Updated the list_detail view to filter items by status, persist the user's choice, and pass status-related context to the template. [1] [2] [3] [4]

Frontend: UI for Status Filtering

• Added a status filter dropdown in list_detail.html, updated Alpine.js state, and ensured filter state is included in form and HTMX requests. [1] [2] [3]

Testing: Test Refactoring and Coverage

• Refactored test setup to create media instances once per test case, and updated/added tests to cover status filtering and UI changes. [1] [2] [3] [4] [5] [6]

[tbmedia]

This is a huge, HUGE feature for most people and I feel like it's being overshadowed by other requests. Allow me to quickly explain my use case, and (other than the high fees now), why I'm leaving Trakt:

I have a custom list of things me and my partner love watching. We filter this list by "unwatched", and boom! All the new things every week pop right up.

Additionally, it would be nice to set a custom order for shows. Bob's Burger's is one of our favorites, it would be so cool to see that as #1. Then, #2 (if there's a new episode) might be something like Hazbin Hotel, another favorite.

I don't see any way to do this on Yamtrack... which is a bummer, because I absolutely love this software. Trakt removed this from their app recently, which was a huge step backwards. If it can be added here, that would be so darn helpful, practical, and COOL. Please consider, and thank you so much for sharing this wonderful software with us!!

Edit: I'm actually going to likely pay Trakt more money at this point purely because I can't seem to find this feature here, or on SIMKL (unless I pay them almost as much as Trakt wants). If there's a way to put a bounty on certain features, I will absolutely fork over cash for a feature like this!

[Copilot]

Pull request overview

This pull request adds status-based filtering functionality to custom list detail views, allowing users to filter list items by their completion status (e.g., Completed, In Progress, Planning, etc.). The implementation includes backend changes to persist user preferences, frontend UI enhancements with a new filter dropdown, and comprehensive test coverage.

Changes:

• Added a list_detail_status field to the User model to persist status filter preferences across sessions
• Implemented status filtering logic in the list_detail view to filter items based on user's status across different media types
• Enhanced the list detail template with a new status filter dropdown UI using Alpine.js and HTMX

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/users/models.py	Added list_detail_status field with MediaStatusChoices and database constraint
src/users/migrations/0038_user_list_detail_status_alter_user_home_sort_and_more.py	Migration to add the new field and constraints
src/lists/views.py	Implemented status filtering logic and updated context to include status choices
src/templates/lists/list_detail.html	Added status filter dropdown UI and integrated with Alpine.js state management
src/lists/tests/test_views.py	Refactored test setup and added test coverage for status filtering

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

When status_filter is not set to ALL, the media objects are fetched and stored in media_by_item_id during the status filtering logic. However, when status_filter is ALL, no media objects are fetched, which means items_page items won't have their media attribute set. This creates inconsistent behavior where items have media objects only when filtering by status but not when showing all items. The media fetching logic that was removed should still execute for items that weren't already processed during status filtering.

[Copilot]

This implementation creates an N+1 query pattern. The code iterates over all items in the queryset with [item.id for item in items], which forces evaluation of the queryset. This happens before any actual filtering, pagination, or processing occurs. For large lists, this could be inefficient. Consider using items.values_list('id', flat=True) instead to avoid loading full Item objects when you only need IDs.

[Copilot]

This implementation creates an N+1 query pattern. The code iterates over all items in the queryset with [item.id for item in items], which forces evaluation of the queryset. This happens before any actual filtering, pagination, or processing occurs. For large lists, this could be inefficient. Consider using items.values_list('id', flat=True) instead to avoid loading full Item objects when you only need IDs.

Suggested change

	"item__in": [item.id for item in items],
	}
	else:
	filter_kwargs = {
	"user": request.user,
	"status": params["status_filter"],
	"item__in": [item.id for item in items],
	"item__in": items.values_list("id", flat=True),
	}
	else:
	filter_kwargs = {
	"user": request.user,
	"status": params["status_filter"],
	"item__in": items.values_list("id", flat=True),

[Copilot]

The mock for update_preference only returns "date_added", but the view calls update_preference twice: once for "list_detail_sort" and once for "list_detail_status". The mock should either use side_effect to return different values for each call, or the test should verify that both calls are being made correctly. Currently, the status filter would get "date_added" as its value which is invalid for MediaStatusChoices, but the update_preference implementation should handle this by returning the current value. This test might not be catching potential bugs in the update_preference logic.

[Copilot]

The comment says "Test the view with media type filter" but this test is actually testing status filtering, not media type filtering. The comment should be updated to accurately reflect what the test does.

Suggested change

	# Test the view with media type filter
	# Test the view with status filter

[Copilot]

The escapejs filter was removed from the query parameter initialization in the Alpine.js data object. This could lead to JavaScript errors or potential XSS vulnerabilities if the query parameter contains quotes or other special characters. The escapejs filter should be restored to properly escape JavaScript strings.

Suggested change

	<div x-data="{ sort: '{{ current_sort }}', type: '{{ request.GET.type|default:'all' }}', status: '{{ current_status }}', query: '{{ request.GET.q|default:'' }}', mediaTypeLabels: {
	<div x-data="{ sort: '{{ current_sort|escapejs }}', type: '{{ request.GET.type|default:'all'|escapejs }}', status: '{{ current_status|escapejs }}', query: '{{ request.GET.q|default:''|escapejs }}', mediaTypeLabels: {

[FuzzyGrim]

Hey, thanks for the PR! I appreciate your work on this.

GitHub Copilot auto-review got triggered somehow (not sure why that happened), and it flagged a few minor issues. The suggestions look valid, but since this PR has been open for a while and the core functionality is solid, I'm going to merge it now and handle those fixes in a follow-up commit.

Thanks again for the contribution!

[FuzzyGrim]

@tbmedia could you create a new issue for that feature request?

[FuzzyGrim]

Added in v0.25.0.