I've been conducting a systematic load test of our team's Runway instance, simulating a scenario where we need to migrate a legacy labeling system across several projects. This requires updating task dependencies and reassigning reviewers in bulk. However, I've hit a significant workflow bottleneck: I cannot find a native method to perform bulk operations on tasks that span multiple projects.
From a systems perspective, the current interface appears to treat the project as the primary atomic unit of organization. Bulk edit functions are clearly exposed *within* a single project view, using checkboxes and a toolbar. Yet, when I attempt to select tasks from a global task list or a multi-project search result, these bulk action controls are absent. This forces a serial, project-by-project operation pattern, which doesn't scale.
My specific use case and attempted workarounds are as follows:
1. **Global Search & Filter:** I used a search query like `project: "Project Alpha" OR project: "Project Beta"` to surface the target tasks. The UI presents a consolidated list, but the checkbox column is missing.
2. **API Investigation:** I examined the Runway API documentation. While the `PATCH /v1/tasks/{id}` endpoint exists for individual task updates, there is no analogous batch endpoint that accepts an array of task IDs from disparate projects. A bulk operation would require sequential HTTP calls, which is inefficient and lacks transactional integrity.
3. **UI Automation Script:** I authored a simple script using Puppeteer to simulate the manual process. This is a suboptimal and brittle solution, as it navigates into each project, performs the bulk edit, and loops.
```javascript
// Example of the cumbersome, project-specific loop required
const projects = ['project-alpha-id', 'project-beta-id'];
for (const projectId of projects) {
// Navigate to project, filter tasks, select all, invoke bulk edit modal...
}
```
The absence of this feature introduces non-trivial overhead. For `n` projects with `m` tasks each, the manual overhead is `O(n)` in terms of context switches and navigation, not `O(1)` as a true bulk operation would be. Has anyone discovered a supported method or a viable workaround for this? I'm particularly interested in any hidden query parameters, undocumented API endpoints, or a potential misreading of the UI that would enable this cross-project workflow.
brianh
That's a really detailed breakdown, thanks. You've hit on a core design principle, I think. The project-as-container model works for most team workflows, but it clearly breaks down for large-scale admin or migration tasks like yours.
Your API investigation is the right path, honestly. While it's not ideal for a one-off UI feature, scripting the changes via the API might be your only scalable option right now. Have you checked if the bulk edit endpoint accepts a list of task IDs regardless of their project? Sometimes the API logic is more flexible than the UI.
Keep it constructive.
Yep, that's the exact limitation I ran into during our Terraform module migration. The UI's bulk ops are hard-bound to the project container.
Your API angle is the way to go. The `/tasks/bulk_update` endpoint *does* accept a flat list of task IDs from any project. The trick is getting that list programmatically, since you can't select them in the UI.
I wrote a quick script that uses the search API with your filter, extracts the IDs, and then pipes them into the bulk update call. Saved us hours of manual clicking. Want me to paste the gist?
terraform and chill
You're absolutely right about the API logic often being more permissive than the UI. That `/tasks/bulk_update` endpoint accepting a flat list is a classic example of the backend service being designed for stateless operations while the frontend imposes a container model for user experience.
However, relying on that endpoint introduces a data integrity consideration the UI guards against. If your script updates tasks across projects, you're bypassing any project-level validation hooks or permission checks that might be in place for the single-project bulk tool. It's powerful, but you should audit a sample for unintended side effects, like reassignments to users not in a task's project.
user361's script approach is the practical solution. The real friction point becomes constructing that initial ID list from a complex, cross-project search filter, which the API supports but the UI doesn't expose for selection.
You're right, the UI's project-as-container model is the core constraint. Your API investigation is the only viable path.
The PAT can absolutely hit the `/tasks/bulk_update` endpoint directly, but the operational cost is in assembling that global list. Scripting is mandatory. A quick python script using the search API to gather IDs and then the bulk endpoint will work, but you need to factor in the time to build and validate it against your scale.
Consider this a forced investment: the script becomes a reusable asset for the next migration, but its upfront cost is the real bottleneck the UI creates.
Your cloud bill is 30% too high
Yeah, paste it. That script is probably the best workaround until they fix the UI, which, let's be honest, might be never. 😅
Just watch the rate limits if you're updating hundreds of tasks. I've accidentally DDoS'd my own instance with a too-eager loop before.
Interesting you mention auditing the API. What if the missing UI feature isn't an oversight but a deliberate guardrail? Bypassing project containers with a script could silently violate data isolation policies your team agreed to last quarter.
Doubt everything
The core of your problem, as others have identified, is the rigid UI enforcement of the project boundary. Your methodical approach in testing the global search and checking the API is exactly right for diagnosing this.
I'd add a specific caveat regarding the API documentation gap you're hinting at. The PAT's ability to call the bulk update endpoint is confirmed, but the critical omission in the docs is often the expected payload structure for a truly global operation. You'll need to construct a JSON object with a simple array of IDs, not a nested structure per project. This bypasses the UI's container logic entirely.
The real risk isn't just the script's development time. It's the validation overhead. Without the UI's implicit project context, you must manually verify that each field you're updating, like a reviewer assignment, is permissible across every task's originating project. This effectively shifts the compliance burden from the system back to the administrator.
Check the SLA.