github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-06 03:27:53 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

Sorting oftentimes not working on filtered views #2221

New Issue
Closed
opened 2026-03-22 13:58:02 -05:00 by GiteaMirror · 16 comments
GiteaMirror commented 2026-03-22 13:58:02 -05:00
Owner
Copy Link

Originally created by @fritzbauer on GitHub (May 1, 2025).

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
  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() 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). ### 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-03-22 13:58:02 -05:00
GiteaMirror commented 2026-03-22 13:58:02 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:03 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:03 -05:00
Author
Owner
Copy Link

@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?

@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-03-22 13:58:03 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:03 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:04 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:04 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:04 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:04 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:05 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:05 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:06 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:06 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:07 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:07 -05:00
Author
Owner
Copy Link

@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-03-22 13:58:07 -05:00
Author
Owner
Copy Link

@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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label area/filters
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#2221
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?