[GH-ISSUE #724] Sorting oftentimes not working on filtered views #6293

New Issue

GiteaMirror · 2026-04-20T16:52:36-05:00

GiteaMirror commented

2026-04-20 16:52:36 -05:00

Originally created by @fritzbauer on GitHub (May 1, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/724

Description

Expected behavior

When sorting tasks via drag and drop on the list view of a saved filter the sort order should be persisted.

Actual behavior

Sorting via Drag and Drop works fine, however when changing to a different page and going to the filtered view again, the sorting is in a different sort order as it was DragNDropped before.

Steps to replicate

Replicated on try.vikunja.io & local git repo:

Create a saved filter "Later" with the criteria done = false && dueDate > now+2d
Go to the project "Inbox" and create tasks "one", "two", "three", "four"
Open Browsers DevTools for network tracing
Open the saved filter view
Check the response of the /projects/:project/views/:view/tasks endpoint --> All tasks will have position: 0
Move the second task "three" one place down and check the Network: It sends a request https://try.vikunja.io/api/v1/tasks/244/position with position 0: {"task_id":244,"project_view_id":369,"position":0}
Switch view to Inbox and back to the filter view --> All tasks will be displayed in a different order than before
Check Network trace --> All tasks will have a proper position value now and sorting works from now on
Go back to Inbox project and add more tasks "five", "six", "seven"
Go back to saved filter view
Check network: The new tasks will have position 0
Drop one of these new tasks down
The position update request will set it to position 0 again
Switch view back and forth again --> The dropped task will have a proper permission value, but the other two new tasks still show position 0.

Issue details

Sorting is not persisted properly whenever there are tasks with position 0 involved. Proper sorting is not possible without any initial position values. So it seems the root cause is that projects/:project/views/:view/tasks does return position values "0".

Solution ideas

I am not familiar with all concepts, therefore I hesitated to create a PR for this. My initial idea would be to use calculateNewPositionForTask() in tasks.go:addMoreInfoToTask() whenever there is no position value in the map for a specific task.

Thank you very much for providing this awesome task management tool!

Vikunja Version

Version: v0.24.1-1119-7b626cd2

Browser and version

Not a frontend problem - replicated in Chrome & Edge

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

No response

Originally created by @fritzbauer on GitHub (May 1, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/724 ### Description ### Expected behavior When sorting tasks via drag and drop on the list view of a saved filter the sort order should be persisted. ### Actual behavior Sorting via Drag and Drop works fine, however when changing to a different page and going to the filtered view again, the sorting is in a different sort order as it was DragNDropped before. ### Steps to replicate Replicated on try.vikunja.io & local git repo: 1. Create a saved filter "Later" with the criteria `done = false && dueDate > now+2d` 2. Go to the project "Inbox" and create tasks "one", "two", "three", "four" 3. Open Browsers DevTools for network tracing 4. Open the saved filter view 5. Check the response of the `/projects/:project/views/:view/tasks` endpoint --> **All tasks will have position: 0** ![Image](https://github.com/user-attachments/assets/1ca637ff-f354-497b-84cc-f944cd29984b) 6. Move the second task "three" one place down and check the Network: It sends a request `https://try.vikunja.io/api/v1/tasks/244/position` with position 0: `{"task_id":244,"project_view_id":369,"position":0}` 7. Switch view to Inbox and back to the filter view --> **All tasks will be displayed in a different order than before** 8. Check Network trace --> **All tasks will have a proper position value now and sorting works from now on** 9. Go back to Inbox project and add more tasks "five", "six", "seven" 10. Go back to saved filter view 11. Check network: The new tasks will have position 0 12. Drop one of these new tasks down 13. The position update request will set it to position 0 again 14. Switch view back and forth again --> **The dropped task will have a proper permission value, but the other two new tasks still show position 0.** ### Issue details Sorting is not persisted properly whenever there are tasks with position 0 involved. Proper sorting is not possible without any initial position values. So it seems the root cause is that `projects/:project/views/:view/tasks` does return position values "0". ### Solution ideas I am not familiar with all concepts, therefore I hesitated to create a PR for this. My initial idea would be to use `calculateNewPositionForTask()` in [tasks.go:addMoreInfoToTask()](https://github.com/go-vikunja/vikunja/blob/4a75f7d4daef02419edd17e6233f86c892f018bf/pkg/models/tasks.go#L747) whenever there is no position value in the map for a specific task. Thank you very much for providing this awesome task management tool! ### Vikunja Version Version: v0.24.1-1119-7b626cd2 ### Browser and version Not a frontend problem - replicated in Chrome & Edge ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots _No response_

GiteaMirror added the area/filters label 2026-04-20 16:52:36 -05:00

GiteaMirror closed this issue

2026-04-20 16:52:37 -05:00

GiteaMirror commented

2026-04-20 16:52:39 -05:00

@kolaente commented on GitHub (May 9, 2025):

Do you only see this with saved filters?

@kolaente commented on GitHub (May 9, 2025): Do you only see this with saved filters?

GiteaMirror commented

2026-04-20 16:52:39 -05:00

@fritzbauer commented on GitHub (May 15, 2025):

I need to admit, in my daily workflow I usually do not sort on project level, but I was not able to replicate the problem on projects itself.

@fritzbauer commented on GitHub (May 15, 2025): I need to admit, in my daily workflow I usually do not sort on project level, but I was not able to replicate the problem on projects itself.

GiteaMirror commented

2026-04-20 16:52:39 -05:00

@kolaente commented on GitHub (Aug 31, 2025):

I've tried replicating this again on the demo just now - it seems to work as expected.

Here's what I did:

Create a saved filter done = false (the actual filter should not matter here)
In the saved filter, reordered some tasks
Refresh the page
All tasks are in the same position as I reordered them

Does this work for you?

@kolaente commented on GitHub (Aug 31, 2025): I've tried replicating this again on the demo just now - it seems to work as expected. Here's what I did: 1. Create a saved filter `done = false` (the actual filter should not matter here) 2. In the saved filter, reordered some tasks 3. Refresh the page 4. All tasks are in the same position as I reordered them Does this work for you?

GiteaMirror commented

2026-04-20 16:52:40 -05:00

@fritzbauer commented on GitHub (Aug 31, 2025):

The problem still occurs. My replication steps above still work - just tested.

In your replication steps you forgot to create any Tasks ;-)

Thanks for your help!

@fritzbauer commented on GitHub (Aug 31, 2025): The problem still occurs. My replication steps above still work - just tested. In your replication steps you forgot to create any Tasks ;-) Thanks for your help!

GiteaMirror commented

2026-04-20 16:52:40 -05:00

@kolaente commented on GitHub (Aug 31, 2025):

There have been tasks in the filter. Does that mean the bug only appears when creating new tasks between reordering?

@kolaente commented on GitHub (Aug 31, 2025): There have been tasks in the filter. Does that mean the bug only appears when creating new tasks between reordering?

GiteaMirror commented

2026-04-20 16:52:41 -05:00

@fritzbauer commented on GitHub (Sep 1, 2025):

Yes, when you create a new task it will have an initial position value of 0.
This is not a problem if you only create a single task, as soon as you sort it it will retrieve a position value which can be calculated from all the other tasks which have position values.
But if many or all tasks do not have a position, it struggles to reorder my task with position 0 after this other task with position 0, but before some more tasks with position 0.

In my workflow I use multiple date based filtered views: today, tomorrow, etc.
When you create a task for a future date it will not be part of the "today" view.
But at some point several of my previously created tasks become a "today" task. And all of them will have a position of 0 initially. So when I do my daily planning I'll sort the tasks just to find a sorting mess after refresh. When ordering for the second time it works since all currently active tasks received a position. When spontaneously adding new tasks for today they will be broken and unsortable.

@fritzbauer commented on GitHub (Sep 1, 2025): Yes, when you create a new task it will have an initial position value of 0. This is not a problem if you only create a single task, as soon as you sort it it will retrieve a position value which can be calculated from all the other tasks which have position values. But if many or all tasks do not have a position, it struggles to reorder my task with position 0 after this other task with position 0, but before some more tasks with position 0. In my workflow I use multiple date based filtered views: today, tomorrow, etc. When you create a task for a future date it will not be part of the "today" view. But at some point several of my previously created tasks become a "today" task. And all of them will have a position of 0 initially. So when I do my daily planning I'll sort the tasks just to find a sorting mess after refresh. When ordering for the second time it works since all currently active tasks received a position. When spontaneously adding new tasks for today they will be broken and unsortable.

GiteaMirror commented

2026-04-20 16:52:41 -05:00

@kolaente commented on GitHub (Sep 1, 2025):

Thanks for clarifying. Does this loosing of the position only affect new tasks (for example, those which "become" today at some point) or all of the tasks already in the filter?

@kolaente commented on GitHub (Sep 1, 2025): Thanks for clarifying. Does this loosing of the position only affect new tasks (for example, those which "become" today at some point) or all of the tasks already in the filter?

GiteaMirror commented

2026-04-20 16:52:42 -05:00

@fritzbauer commented on GitHub (Sep 1, 2025):

The tasks which are in the filter at creation time of the filter will be sortable (as shown by your replication steps above)
Any task which is new will not be sortable. "New" could mean it either "became" today, or I created a new task (as shown by my replication steps above). Whenever a task occurs first in a filter it will not have a position value.

@fritzbauer commented on GitHub (Sep 1, 2025): * The tasks which are in the filter at creation time of the filter will be sortable (as shown by your replication steps above) * Any task which is new will not be sortable. "New" could mean it either "became" today, or I created a new task (as shown by my replication steps above). Whenever a task occurs first in a filter it will not have a position value.

GiteaMirror commented

2026-04-20 16:52:42 -05:00

@kolaente commented on GitHub (Sep 11, 2025):

This should be fixed in https://github.com/go-vikunja/vikunja/pull/1477, please check with the next unstable build (should be ready for deployment in ~30min, also on try).

@kolaente commented on GitHub (Sep 11, 2025): This should be fixed in https://github.com/go-vikunja/vikunja/pull/1477, please check with the next unstable build (should be ready for deployment in ~30min, also on [try](https://try.vikunja.io)).

GiteaMirror commented

2026-04-20 16:52:43 -05:00

@fritzbauer commented on GitHub (Sep 12, 2025):

Unfortunately, it did not help. I just confirmed it on try.vikunja.io and my private instance. Both on Version: v1.0.0-rc2.
Original replication steps still work and network trace also shows that the initial position parameter for new tasks is 0.

@fritzbauer commented on GitHub (Sep 12, 2025): Unfortunately, it did not help. I just confirmed it on try.vikunja.io and my private instance. Both on Version: v1.0.0-rc2. Original replication steps still work and network trace also shows that the initial position parameter for new tasks is 0.

GiteaMirror commented

2026-04-20 16:52:43 -05:00

@vikunja-bot-app[bot] commented on GitHub (Dec 16, 2025):

This issue has been fixed in #1996, please check with the next unstable build (should be ready for deployment in ~30min, also on the demo).

@vikunja-bot-app[bot] commented on GitHub (Dec 16, 2025): This issue has been fixed in #1996, please check with the next unstable build (should be ready for deployment in ~30min, also on [the demo](https://try.vikunja.io)).

GiteaMirror commented

2026-04-20 16:52:44 -05:00

@fritzbauer commented on GitHub (Dec 17, 2025):

Unfortunately, it did not help. I just confirmed it on try.vikunja.io with Version: v1.0.0-rc3-108-8adf0ef0
Original replication steps still work and network trace also shows that the initial position parameter for new tasks is 0.

@fritzbauer commented on GitHub (Dec 17, 2025): Unfortunately, it did not help. I just confirmed it on try.vikunja.io with Version: v1.0.0-rc3-108-8adf0ef0 Original replication steps still work and network trace also shows that the initial position parameter for new tasks is 0.

GiteaMirror commented

2026-04-20 16:52:44 -05:00

@kolaente commented on GitHub (Jan 11, 2026):

I've tried to reproduce this again with the steps originally posted here, but it seems to work - are you still able to reproduce it consistently? Please share your steps.

@kolaente commented on GitHub (Jan 11, 2026): I've tried to reproduce this again with the steps originally posted here, but it seems to work - are you still able to reproduce it consistently? Please share your steps.

GiteaMirror commented

2026-04-20 16:52:44 -05:00

@fritzbauer commented on GitHub (Jan 11, 2026):

Thank you very much that you continue to follow-up on issues which are hard to trace to its cause!
Good news: I just tried to replicate on try.vikunja.io again and it did not occur anymore.

(Seems the deployment was delayed when I tested it after your comment last month. As mentioned try.vikunja was on v1.0.0-rc3-108-8adf0ef0 and it seems this version did not contain your fixes from December 16th yet: https://github.com/go-vikunja/vikunja/commits/8adf0ef0 )

I am fine to close this issue.

Just to be fair wanted to provide some background info:

I have a scheduled job running 4 times a day to fix the sorting (and create recurring tasks for patterns which are not configurable in Vikunja at the moment - but that's a different topic). I just checked this jobs logs.
This job was logging many fixed tasks which initially had the position value 0 until 2025-12-17.
After that date the majority of tasks is fine, but still occasionally there were some tasks with position 0 returned.
- 2025-12-19: 1 Task
- 2025-12-21: 1 Task
- 2025-12-22: 2 Tasks
- 2025-01-05: 2 Tasks
- 2ß25-01-08: 2 Tasks
As this is not very often and only for very few tasks, it does not have a real world impact at this point.

@fritzbauer commented on GitHub (Jan 11, 2026): Thank you very much that you continue to follow-up on issues which are hard to trace to its cause! Good news: I just tried to replicate on try.vikunja.io again and it did not occur anymore. (Seems the deployment was delayed when I tested it after your comment last month. As mentioned try.vikunja was on v1.0.0-rc3-108-8adf0ef0 and it seems this version did not contain your fixes from December 16th yet: https://github.com/go-vikunja/vikunja/commits/8adf0ef0 ) I am fine to close this issue. Just to be fair wanted to provide some background info: * I have a scheduled job running 4 times a day to fix the sorting (and create recurring tasks for patterns which are not configurable in Vikunja at the moment - but that's a different topic). I just checked this jobs logs. * This job was logging many fixed tasks which initially had the position value 0 until 2025-12-17. * After that date the majority of tasks is fine, but still occasionally there were some tasks with position 0 returned. * 2025-12-19: 1 Task * 2025-12-21: 1 Task * 2025-12-22: 2 Tasks * 2025-01-05: 2 Tasks * 2ß25-01-08: 2 Tasks * As this is not very often and only for very few tasks, it does not have a real world impact at this point.

GiteaMirror commented

2026-04-20 16:52:45 -05:00

@kolaente commented on GitHub (Jan 11, 2026):

Glad this is solved! I'll close the issue then.

For recurring task patterns, you might be interested in this PR: https://github.com/go-vikunja/vikunja/pull/2032
It will still take a while until that gets merged, but it might solve your need for a scheduled job.

@kolaente commented on GitHub (Jan 11, 2026): Glad this is solved! I'll close the issue then. For recurring task patterns, you might be interested in this PR: https://github.com/go-vikunja/vikunja/pull/2032 It will still take a while until that gets merged, but it might solve your need for a scheduled job.

GiteaMirror commented

2026-04-20 16:52:45 -05:00

@vikunja-bot-app[bot] commented on GitHub (Jan 11, 2026):

This issue has been fixed in #1996, please check with the next unstable build (should be ready for deployment in ~30min, also on the demo).

@vikunja-bot-app[bot] commented on GitHub (Jan 11, 2026): This issue has been fixed in #1996, please check with the next unstable build (should be ready for deployment in ~30min, also on [the demo](https://try.vikunja.io)).

Sign in to join this conversation.

Branches Tags

main

renovate/dev-dependencies

feat-v2-foundation

dependabot/npm_and_yarn/frontend/axios-1.15.2

spike-huma-openapi3

claude/investigate-swagger3-support-nyyUa

feat-list-view-buckets

ci-mysql-8-test

codex/analyze-codebase-for-email-task-feature

feat-project-templates

csv-import-feature

claude/email-reply-comments-wpdcQ

fix-oidc-pkce-support

fix/overview-subtasks-expand

feat/bucket-select-task-detail

feat-soft-delete-projects

claude/review-bot-design-plan-cf5C3

claude/project-scoped-api-tokens-KTqR3

claude/explore-openclaw-integration-KQEzg

claude/project-scoped-api-tokens-yv5KS

fix-duplicate-close-button

feat-list-view-sorting

feat/official-vite-sentry-plugin

feat/highlight-overdue-tasks

feat/add-enter-key-form-submission-handling

feat/TipTap-nits

feat/update-caldavtimetotimestamp-parsing

feat-phosphor-icons

wip-plans

claude/investigate-issue-2173-llKme

fix-description-text-drag

feat-custom-keyboard-shortcuts

pr-1845-ci

codex/fix-drag-and-drop-behavior-inconsistency

copilot/add-clickable-labels-for-filtering

copilot/fix-issue-1786

playwright-migration

fix-kanban-repeating-wip

copilot/fix-1498

feature/replace-axios

codex/upgrade-to-tailwind-4.1.8-using-pnpm

codex/add-cypress-test-for-avatar-types

feature/biome

feature/oxc

codex/update-flexsearch-to-0.8.205

4r6ni9-codex/fix-deprecated-sass-@import-usage

codex/fix-deprecated-sass-@import-usage

codex/add-cypress-test-for-task-list-refresh-fix

codex/fix-quick-add-magic-not-adding-tasks

codex/fix-all-type-errors

codex/fix-mimetype-for-docs.json

feature/caldav-from-scratch

feature/gh-actions-hetzner

fix-ci

feat/new-logger

jyte-better-dev-config

feat/add-team-member-with-enter

fix/button-and-icon-types

fix/notifications-component-name-collision

feature/null-time

renovate/tailwindcss-4.x

feature/unplugin-vue-router

fix/deprecated-import

feature/zod-schema

renovate/golangci-golangci-lint-1.x

fix/tiptap-editor-reactive-destructuring

release/0.24

feat/improve-add-task

fix/saved-filter-search

feat/webp-and-avif-attachment-previews

feature/migrate-back-to-bulma

fix/sass-add-missing-list-import

feature/sticky-demo-bar

fix/gantt-view-switch

feature/typesense-position-join

feature/focus-visible

dependencies/golangci-lint

feature/better-filter-syntax

fix/tiptap-task-list

renovate/github.com-golang-jwt-jwt-v4-5.x

feature/hide-forbidden-related-tasks

renovate/golang-1.x

release/0.20

release/0.17

release/0.16

release/0.15

release/0.14

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vikunja#6293