After D20305, this can be "fixed" with this change:

To summarize the state of the world here:

In T6409#216988, @denghaodna wrote:

Would be happy to see this feature. My company use different team names as columns of the work board. When a task is reassigned from a dev to a tester, I need to manually move it from Dev column to QA column.
With this feature implemented, I would be able to configure a rule that when a task is assigned to a specific person, the task will be automatically moved to a column, say the Dev column for example.

It sounds like real-time updates will more-or-less moot this.

This isn't an actionable task. It covers too much ground, describes too many features, and most of it lacks compelling use cases.

No plan to continue on this?

@epriestley we are using the "menu item" solution that you described above, and the primary remaining pain point is that when you click on a link, the menu highlights "workboard", which confuses some users, because they expect the link (i.e. the menu item they just clicked on) to be highlighted.

Awesome, thanks @epriestley!

Sorry! That reproduces cleanly for me too. I must have made a mistake following the reproduction steps or overlooked something. D19768 should fix this.

I just tested and indeed @joshuaspence's steps are reproducible on https://phabricator.wikimedia.org

In T13208#242142, @epriestley wrote:

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.

These reproduction steps don't work for me, and don't make sense given how the software works. If you believe you have a set of reproduction steps, can you walk through them step-by-step in more detail so I can reproduce the issue?

If anyone can come up with reproduction steps which actually work, this will probably take me about 3 minutes to fix. The only thing blocking this is that I have no idea how to reproduce it.

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.

I just a way to fix this. After using "/query/all" to get in the board. We can click on the "All Tasks" Filter -> "Save as Default" and we don't get issue 404 anymore.

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.
Workaround: add "/query/all" at the end of the url also work fine.
I am still reviewing the database to to set back to the buitin query

In T13208#242133, @20after4 wrote:

@dlgiang: if you go to maniphest and choose any of the existing saved queries, you will find the ID in the resulting url.

@dlgiang: if you go to maniphest and choose any of the existing saved queries, you will find the ID in the resulting url.

In T13208#242106, @aklapper wrote:

@dlgiang: T13208#241682 above links to https://phabricator.wikimedia.org/T199207#4413718 describing a workaround

@dlgiang: T13208#241682 above links to https://phabricator.wikimedia.org/T199207#4413718 describing a workaround

Are there any workaround for this issue ?

It seems to be a fairly recent problem so there must be some code change that started triggering it. The worst part, IMO, is that the workboard breaks in a not-entirely-obvious way instead of falling back to a default query. It took me a while to debug the issue the first time it occurred.

There should be no code anywhere in Phabricator to delete saved queries. The expectation is that they are never deleted or garbage collected because they may have been embedded in other pages, sent via email, etc., and deleting a saved query will break any use of the link in a permanent/external context. The table is expected to grow without bound, although at a slow enough rate that it does not create a maintainability issue.