Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make fetching workspaces deleted query param consistent #2176

Open
Emyrk opened this issue Jun 8, 2022 · 9 comments
Open

Make fetching workspaces deleted query param consistent #2176

Emyrk opened this issue Jun 8, 2022 · 9 comments
Labels
backend chore good first issue

Comments

@Emyrk
Copy link
Member

@Emyrk Emyrk commented Jun 8, 2022

Currently if you attempt to fetch a deleted workspace, if it is deleted you need to include ?deleted=true query parameter. We also have a include_deleted query param in the case that it will return regardless if it is deleted or not.

If you fetch workspaces, then the ?deleted query param only shows deleted workspace OR it shows active workspaces. It will never show a mixed set of deleted and active. From a UI perspective, this is kinda strange, as you'd assume there are cases you want the mixed set.

Proposal

We should keep only the ?deleted query param and treat it as follows:

  • deleted="" : Show both deleted and active
  • This is the default case
  • `deleted="false": Show only active
  • deleted="true": Show only deleted

The empty string applies no filters and returns the mixed set. We should add a Deleted field to Workspace data type for the user to see the workspace status.

Reasoning

Fetching single

When fetching a single workspace, we already have the id or the name. We want to know if the workspace exists regardless of it's state. They should check the Deleted field to know if it's active or not. I assume we might even allow the workspace to be brought back to life in the future?

If they want to only see active/deleted they can use the deleted query param

Fetching multiple

In our other filters we treat empty string as "do not apply the filter", so the same case goes here. We just need that Deleted field for the user to know the status.
@Emyrk Emyrk added good first issue backend chore labels Jun 8, 2022
@Kira-Pilot
Copy link
Member

@Kira-Pilot Kira-Pilot commented Jun 8, 2022

This is a great writeup; thanks for adding it. I think your reasoning is solid and an implementation as described above would definitely make our lives easier.

@Emyrk
Copy link
Member Author

@Emyrk Emyrk commented Jun 8, 2022

@misskniss @tjcran A good one for the prettier issue: #1939

@ketang
Copy link
Contributor

@ketang ketang commented Jun 9, 2022

Can we instead treat deletion status the same way we intend to treat other search fields? Then it ends up as part of the query string currently used just for owner instead of a different query parameter. The way that might look is either deleted:true or status:deleted or is:deleted. I favor status:deleted. I think there's a lot to be said for combining all search parameters into a single query (search query not HTTP parameter although that ends up being the same).

@f0ssel

@Emyrk
Copy link
Member Author

@Emyrk Emyrk commented Jun 9, 2022 •
edited

@ketang that is how it can be done on the FE. On the backend owner:me is translated into ?owner=me.

If you mean changing deleted=true on the BE to status=deleted, I think we'd have to suggest that deleted is a type of "transition"?

Also currently we do not use joins on the BE, so query wise, we cannot support status=start or status=stop on a database level (which is the best place to filter). I do have an issue that would allow joins: #2201

@Emyrk
Copy link
Member Author

@Emyrk Emyrk commented Jun 9, 2022 •
edited

Ok so as I look more into this, it looks like we can have many deleted workspaces with the same name. So GetWorkspaceByOwnerAndName will only return 1 of these deleted workspaces... which is weird.

For the list, include_deleted=true makes more sense then deleted="" as I think fetching deleted workspaces is pretty niche.

@ketang
Copy link
Contributor

@ketang ketang commented Jun 9, 2022

We should use that query syntax in API calls as well. It shouldn't be something we do on the front end only. I see value in this for general API use but also the CLI. coder workspaces search (or list takes arguments potato batata).

@Emyrk
Copy link
Member Author

@Emyrk Emyrk commented Jun 9, 2022

@ketang I support passing the query directly.

@Emyrk
Copy link
Member Author

@Emyrk Emyrk commented Jun 9, 2022

After chatting with @f0ssel @Kira-Pilot we decided not to allow showing deleted workspaces in the workspace list view. It's not needed and can actually cause more issues than it's worth.

I made WorkspaceByID and WorkspaceByOwnerAndName match include_deleted and fixed which deleted workspace is returned in WorkspaceByOwnerAndName. There was a bug if you deleted the same workspace name more than once.

This will suffice for community mvp.
#2214

@ketang ketang mentioned this issue Jun 9, 2022
Open
@ketang
Copy link
Contributor

@ketang ketang commented Jun 9, 2022

#2217 for doing this query on the back end instead of making the front end responsible for mapping from the search query to the API parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
backend chore good first issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ketang @Emyrk @Kira-Pilot