Vikunja Saved Filters: Stop Duplicate Subtasks

The Problem with Subtask Duplication in Vikunja Saved Filters

Have you ever found yourself staring at your Vikunja tasks, trying to get a clear overview, only to be bombarded with duplicated subtasks? It's a frustrating experience, and it often stems from how saved filters are handled, especially when dealing with multiple projects. When you create a view using a query that includes multiple projects, like project = FirstProject || project = SecondProject || project = ThirdProject, Vikunja can unintentionally duplicate subtasks within that view. This means that instead of seeing a clean, organized list of your tasks and their associated subtasks, you end up with a messy, redundant display. Imagine having a parent task with a couple of children, and then seeing those same children appear again, completely unattached to their parent, just because they belong to one of the projects included in your filter. It makes it incredibly difficult to track progress, manage your workload, and maintain a clear understanding of your project structure. This isn't just a minor visual glitch; it's a significant usability issue that can hinder productivity and lead to confusion. The goal of a task management system like Vikunja is to bring clarity and order to your work, and when subtasks are duplicated, that clarity is lost. This article aims to delve into why this happens and explore potential solutions or workarounds to ensure your saved filters display your tasks exactly as you intend, without the clutter of unnecessary duplicates. We'll be discussing the specific scenario that triggers this bug and how it impacts the user experience, particularly for those managing tasks across several projects.

Understanding the Root Cause of Duplicate Subtasks

Let's dive a little deeper into why these duplicate subtasks appear in your Vikunja saved filters. The core of the issue lies in how the filtering logic processes tasks and their relationships across multiple projects. When a filter query includes an OR condition across different projects (e.g., tasks from Project A OR Project B OR Project C), the system might interpret this as a command to list all tasks that match any of these project criteria, independent of their parent-child relationships. This means a subtask belonging to a parent task in Project A might be listed because it's in Project A, and if that same subtask also happens to be queryable (perhaps it's a standalone task or has a different linking mechanism in play) within the context of Project B (even if it's not directly associated with a parent in Project B), it could be picked up again. The way the query project = FirstProject || project = SecondProject || project = ThirdProject works is by checking each task against each condition. If a task (or subtask) satisfies any of these conditions, it's included in the results. The problem arises because subtasks are often treated as distinct entities within the project structure, and the filter doesn't always intelligently recognize that a subtask already displayed under its parent should not be listed again as a top-level item if it also meets a project criteria. This leads to the visual anomaly where you see:

__ parent1
____ child1
____ child2
__ child1
__ child2

Notice how child1 and child2 appear twice: once correctly nested under parent1, and again as standalone tasks. This duplication occurs because the filter finds parent1 in FirstProject, and then lists its children (child1, child2). Subsequently, if child1 and child2 themselves happen to be queryable within FirstProject or SecondProject (or any other project in the OR condition), they get listed again as separate entries. It's a classic case of the filter being too broad and not having a specific mechanism to deduplicate items that have already been displayed within a hierarchical context. The intention of such a query is usually to see all tasks within a set of projects, but the implementation inadvertently breaks the hierarchical view of subtasks when multiple projects are involved in an OR clause. This behavior can be particularly confusing when you're trying to manage complex projects with nested tasks, as it obscures the actual structure and makes it hard to see what needs attention.

The Impact on User Experience and Productivity

The duplication of subtasks in Vikunja saved filters isn't just an aesthetic flaw; it has a tangible negative impact on how users interact with the software and, consequently, on their productivity. When you're presented with a view where tasks and subtasks are repeated, the immediate effect is a loss of clarity. Imagine you have a complex project with several layers of subtasks, and your saved filter is supposed to give you a quick snapshot of what's most important. Instead, you're faced with a cluttered list where you have to mentally sift through duplicates to find the actual, unique items you need to work on. This requires extra cognitive load. You have to pause, identify the duplicates, and then figure out which entry is the