Context
The frontend now ships a batch task-creation UI that drafts many tasks locally and submits them in a single createTasksBatch(bytes32 pid, CreateTaskInput[] tasks) call. This works well for unassigned tasks, but the contract's CreateTaskInput has no assignee field, so any drafted task that targets a specific user has to fall back to one-by-one createAndAssignTask calls — which defeats the point of batching.
Ask
Add per-item assignment support to the batch entry point. Two shapes worth considering:
- New struct + new function —
createAndAssignTasksBatch(bytes32 pid, CreateAndAssignTaskInput[] tasks) where CreateAndAssignTaskInput is CreateTaskInput plus address assignee. Keeps createTasksBatch clean for the unassigned case.
- Optional parallel array —
createTasksBatch(bytes32 pid, CreateTaskInput[] tasks, address[] assignees) where assignees[i] == address(0) means "leave unassigned". Slight UX win but a wider attack surface for callers passing a mismatched array length; revert if len(assignees) != 0 && len(assignees) != len(tasks).
Either works for the frontend; (1) is probably the cleaner ABI.
Frontend follow-up
Once shipped, we'll re-enable the Assign field in batch mode in AddTaskModal (currently hidden via allowAssign={false} from the batch entry path) and route mixed-assignment drafts through whichever new function this issue produces.
Context
The frontend now ships a batch task-creation UI that drafts many tasks locally and submits them in a single
createTasksBatch(bytes32 pid, CreateTaskInput[] tasks)call. This works well for unassigned tasks, but the contract'sCreateTaskInputhas no assignee field, so any drafted task that targets a specific user has to fall back to one-by-onecreateAndAssignTaskcalls — which defeats the point of batching.Ask
Add per-item assignment support to the batch entry point. Two shapes worth considering:
createAndAssignTasksBatch(bytes32 pid, CreateAndAssignTaskInput[] tasks)whereCreateAndAssignTaskInputisCreateTaskInputplusaddress assignee. KeepscreateTasksBatchclean for the unassigned case.createTasksBatch(bytes32 pid, CreateTaskInput[] tasks, address[] assignees)whereassignees[i] == address(0)means "leave unassigned". Slight UX win but a wider attack surface for callers passing a mismatched array length; revert iflen(assignees) != 0 && len(assignees) != len(tasks).Either works for the frontend; (1) is probably the cleaner ABI.
Frontend follow-up
Once shipped, we'll re-enable the Assign field in batch mode in
AddTaskModal(currently hidden viaallowAssign={false}from the batch entry path) and route mixed-assignment drafts through whichever new function this issue produces.