hoangsonww / hoangsonww/Task-Manager-ReactNative

Feature: Add bulk task operations with transactional safety and undo

Open
#17 0 comments 0 reactions 1 assignee Claimed by @hoangsonww View on GitHub
accessibility bug documentation enhancement good first issue help wanted question
Dominant language
TypeScript
Stars
32
Forks
8
PR merge metrics
No merged PRs in 30d

Description

## Summary

Enable users to select multiple tasks and apply common changes safely, with clear progress, partial-failure handling, and undo.

## Problem / Opportunity

TaskNexus currently exposes mutations one task at a time. Cleaning up a backlog, rescheduling a group, or closing several related tasks requires repetitive interaction and produces many independent realtime updates, increasing effort and the chance of inconsistent results.

## Proposed Feature

Add an explicit multi-select mode on Home and a bulk action surface for complete/reopen, delete, due-date change, and color change. Execute operations through a well-defined batch mutation path, keep connected clients coherent, and provide undo or recovery where feasible.

## Scope

- Add enter/exit selection mode, select-all-visible, range/keyboard selection on web, and accessible selection announcements.
- Define which filtered/visible task set “select all” targets.
- Add batch mutation service/RPC behavior with authorization, validation, progress, cancellation boundaries, and result reporting.
- Integrate optimistic UI carefully with Supabase realtime reconciliation.
- Add confirmation and undo/recovery for destructive actions.
- Document operational limits and test concurrency/failure scenarios.

## Acceptance Criteria

- [ ] Users can enter selection mode without accidentally opening, completing, dragging, or deleting a task.
- [ ] Individual, all-visible, and clear-selection controls expose accurate selected counts.
- [ ] Bulk complete/reopen, delete, due-date change, and color change operate only on owned selected tasks.
- [ ] The server-side path validates authorization for every target and defines atomic versus partial-success behavior.
- [ ] Large selections show progress and a final created/updated/skipped/failed-style result summary as applicable.
- [ ] Destructive bulk actions require confirmation and support documented undo or Trash recovery.
- [ ] Realtime updates from the batch do not duplicate items, reset unrelated selection, or leave stale task state.
- [ ] Keyboard and screen-reader users can select tasks and invoke every bulk action.
- [ ] Tests cover mixed-validity selections, concurrent edits, network interruption, retries, and auth isolation.
- [ ] Documentation explains selection scope, limits, failure semantics, and recovery.

## Non-Goals

- Cross-user administrative bulk actions.
- Arbitrary spreadsheet-style inline editing.
- Bulk changes to future metadata not yet implemented.

## Dependencies / Risks

- Per-row updates may cause event storms; a database function or coordinated batching strategy may be required.
- Optimistic updates are risky when only part of a batch succeeds.
- Drag gestures and row presses must be disabled or reinterpreted clearly during selection mode.

## Open Questions

- Should “select all” mean all currently loaded rows or every task matching the active filter?
- Which operations must be atomic?
- What selection-size limit protects mobile performance and backend quotas?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.