feat(tasks): implement bulk task actions (complete/delete)

[ShivaGupta-14]

Description

This PR introduces bulk task actions to CCSync, allowing users to efficiently manage multiple tasks at once. Users can now select multiple tasks via checkboxes and perform bulk operations like "Mark as Completed" or "Delete" through a floating action panel.

Key Enhancements

• Added checkboxes to individual task rows and a "Select All" checkbox in the table header
• Implemented a floating action panel that appears when tasks are selected
• Added backend endpoints for bulk complete (POST /complete-tasks) and bulk delete (POST /delete-tasks)
• Updated frontend state to efficiently track selected UUIDs
• Added confirmation dialogs and loading states for better user experience
• Added comprehensive tests for bulk selection logic, API integration, and UI interactions

Implementation Details

The bulk selection state is managed locally within the Tasks component using a Set of UUIDs to ensure O(1) lookups and efficient updates.

• Frontend:
  • The selectedTaskUUIDs state tracks which tasks are currently selected.
  • A floating action bar is conditionally rendered when selectedTaskUUIDs.size > 0.
  • "Select All" logic toggles between adding all visible task UUIDs to the set or clearing it entirely.
• Backend:
  • Two new endpoints were created to handle batch operations: /complete-tasks and /delete-tasks.
  • Both endpoints accept a JSON body containing an array of uuids.
  • The backend iterates through the provided UUIDs and performs the requested action (modify status or delete) transactionally where possible to ensure data consistency.

Fixes: #178

---

Checklist

• Ran npx prettier --write . (for formatting)
• Ran gofmt -w . (for Go backend)
• Ran npm test (for JS/TS testing)
• Added unit tests, if applicable
• Verified all tests pass
• Updated documentation, if needed

---

Additional Notes

Video: Click here to see

Screenshots:

[its-me-abhishek]

While the current behavior might work, there are a couple of edge cases worth considering:

1. If a task is already completed or deleted, and the user selects it again for deletion, the operation becomes a false positive-- the task is already gone, so it only adds unnecessary load on the server.
2. Marking a deleted task as completed would also require switching its status back first, which creates an avoidable extra step.

[ShivaGupta-14]

Hey @its-me-abhishek, thanks for the feedback!

I've addressed both edge cases you mentioned:

1. Deleted tasks: Checkboxes are now disabled for deleted tasks, and "Select All" only selects non-deleted tasks.
2. Completed tasks: The bulk complete button is now hidden whenever any completed task is selected. It only reappears when all completed tasks are deselected.

This prevents unnecessary server load from re-completing already completed tasks or attempting operations on deleted tasks.

Let me know if you'd like any adjustments!

[its-me-abhishek]

Marking as draft for now, will re review once #236 gets merged

[ShivaGupta-14]

Hi @its-me-abhishek , since #236 is merged, I've resolved the conflicts and the PR is now ready. Please review it once you get a chance!

[ShivaGupta-14]

Hi @its-me-abhishek, since #236 is merged and the conflicts are resolved, could you please mark this PR as ready for review when you get a chance? Thanks!

[github-actions]

Thank you for opening this PR!

Before a maintainer takes a look, it would be really helpful if you could walk through your changes using GitHub's review tools.

Please take a moment to:

• Check the "Files changed" tab
• Leave comments on any lines for functions, comments, etc. that are important, non-obvious, or may need attention
• Clarify decisions you made or areas you might be unsure about and/or any future updates being considered.
• Finally, submit all the comments!

More information on how to conduct a self review:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request

This helps make the review process smoother and gives us a clearer understanding of your thought process.

Once you've added your self-review, we'll continue from our side. Thank you!

[ShivaGupta-14]

created new endpoint for bulk task completion. uses a single job for all UUIDs.

[its-me-abhishek]

this is a O(n) operation with lots of Config->Operate->Sync tasks, preferably what shall be done could be that- add another CMD operation for this called CompleteTasksInTaskwarrior, and then operate that loop there, instead of this API that initiates the Job. So they would have a single SetConfig->MultipleOperations->SingleSync as the final workflow. Similar shall be done for delete so as to reduce server overheads

[ShivaGupta-14]

@its-me-abhishek
Thanks for the suggestion! I understand, I'll refactor to move the loop into a single CompleteTasksInTaskwarrior function with the flow: SetConfig -> Loop operations -> SingleSync.

Quick question: for tracking which individual tasks fail within the batch, should I return a map[string]string (uuid -> error) or define a struct like FailedTask{UUID, Error}? Both work, just wondering if you have a preference.

[ShivaGupta-14]

@its-me-abhishek self-review completed! ready for your review. (Note: As mentioned on Zulip, merging this before conflicting PRs would be helpful due to the filter-repo issue.)