The calendar VTODO deep link redirects to a /flow-tasks route that does not exist

[rubenvdlinde]

What

TaskController::open() redirects the calendar VTODO deep link to a route that does not exist, in a form the router no longer reads.

lib/Controller/TaskController.php:169:

return new RedirectResponse(rtrim($base, '/') . '/#/flow-tasks/' . $safeUuid);

Two separate things are wrong with that target:

1. The hash form no longer routes. #3270 moved openregister to createWebHistory, so …/#/flow-tasks/<uuid> lands on the app's default route rather than the task.
2. There is no /flow-tasks route at all. Grepping src/ for flow-tasks returns nothing, and no manifest page declares that route. So even written as a path it would resolve nowhere.

Why it is not caught

tests/e2e/task-projections.spec.ts:164 asserts only the redirect's Location header:

expect(followed.headers().location).toContain(`#/flow-tasks/${task.uuid}`)

It never follows the redirect to a rendered page, so it passes whether or not the target resolves. The test agrees with the code, and both are wrong about the same thing.

Impact

This is the link in the projected VTODO. An assignee who opens the task from their calendar reaches the dashboard, not the task, with no error.

Not fixed in #3306

I found this while fixing that PR's two E2E failures and deliberately left it: choosing the right target is a product decision, not a mechanical one. Someone needs to say whether the task opens on a dedicated /flow-tasks/:uuid route that still has to be built, or on an existing surface such as the task inbox.

Whatever the answer, the e2e assertion should follow the redirect rather than read its header.

Adjacent

lib/Service/TaskService.php:356 builds …/#/calendars/<uri>/tasks/<uri>, which is correct and should not be changed: that one points at the Nextcloud Tasks app (tasks.page.index), which does route on the hash.

[github-actions]

Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

What happens next:

1. A maintainer will review this issue and determine the appropriate action
2. If accepted, it may be converted into an OpenSpec change for structured development
3. You will be notified of any status changes

Triage labels:

• triage:accept-feature — accepted as a new feature
• triage:accept-bugfix — accepted as a bug fix
• triage:needs-info — more information needed
• triage:wontfix — will not be addressed
• triage:duplicate — duplicate of another issue

[rubenvdlinde]

Closing: both halves of this were fixed by other work, and the leftover is now cleaned up in #3337.

The redirect is gone. #3315 (wire the fleet task inbox into the UI) rewrote TaskController::open() to return a TemplateResponse serving the SPA shell directly.

The route exists. /flow-tasks/:uuid is flow-task-detail in src/main.js, described there as the one stable address every VTODO URL and notification button carries.

So the product question this issue was holding open — where a task should open — is answered in code, and there is nothing left to decide.

What remained was a test asserting the old contract: task-projections.spec.ts still expected 302/303 with Location containing #/flow-tasks/<uuid>. It survived both changes because that block skips whenever the assignee has no VTODO-capable calendar, and CI's admin has none — No VTODO-supporting calendar found for user admin is in the server logs. It had been asserting a contract that stopped existing without ever running to say so. #3337 points it at what open() actually does.