Some thoughts:

• We can make it in the FE only
• I think making this in the BE can be tricky since the status is not a "well computed" value, and we are doing that in the FE. To make this happen in the BE, we should refactor the BE to compute the status and after, use it to filter the workspaces. Not sure how this could happen with the DB.

@f0ssel this is where we translate from api values to workspace status (and then there's another translation to the actual wording used in various places, so like the status started displays as Running) https://github.com/coder/coder/blob/main/site/src/util/workspace.ts#L55

If we move this logic (transition + job status -> workspace status, that is; we can handle display labels on the frontend) to the backend, then adding a filter for running workspaces will be simple on the frontend.

Alternatively, if there is some way for the frontend to send a query that the backend can already understand (like transition=start&status=succeeded or something), that's also okay for the frontend.

Sounds good, I'll see what looks easier, will probably ping @coadler for some heavy lifting on the DB side.

Some thoughts:

• We can make it in the FE only
• I think making this in the BE can be tricky since the status is not a "well computed" value, and we are doing that in the FE. To make this happen in the BE, we should refactor the BE to compute the status and after, use it to filter the workspaces. Not sure how this could happen with the DB.

I think we need to approach these search and filtering features as backend ones, as they're most relevant to larger deployments where our current one-page solution presents poorly.