Skip to content

feat: Add suspend/active user to cli #1422

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

Merged
merged 16 commits into from
May 16, 2022
Merged

Conversation

Emyrk
Copy link
Member

@Emyrk Emyrk commented May 13, 2022

coder users activate <username | user_id>
coder users suspend <username | user_id>

@codecov
Copy link

codecov bot commented May 13, 2022

Codecov Report

Merging #1422 (2ed4249) into main (64a8b4a) will increase coverage by 0.12%.
The diff coverage is 75.57%.

@@            Coverage Diff             @@
##             main    #1422      +/-   ##
==========================================
+ Coverage   67.07%   67.19%   +0.12%     
==========================================
  Files         287      292       +5     
  Lines       19307    19612     +305     
  Branches      241      258      +17     
==========================================
+ Hits        12950    13179     +229     
- Misses       5016     5079      +63     
- Partials     1341     1354      +13     
Flag Coverage Δ
unittest-go-macos-latest 54.42% <75.57%> (+0.35%) ⬆️
unittest-go-postgres- 65.71% <75.57%> (+0.23%) ⬆️
unittest-go-ubuntu-latest 56.80% <75.57%> (+0.17%) ⬆️
unittest-go-windows-2022 52.78% <75.57%> (+0.37%) ⬆️
unittest-js 74.73% <ø> (+0.08%) ⬆️
Impacted Files Coverage Δ
coderd/users.go 61.80% <57.14%> (+0.36%) ⬆️
cli/userstatus.go 70.00% <70.00%> (ø)
codersdk/users.go 65.12% <84.61%> (+1.33%) ⬆️
cli/userlist.go 71.42% <100.00%> (-11.43%) ⬇️
cli/users.go 100.00% <100.00%> (ø)
coderd/coderd.go 94.65% <100.00%> (+0.06%) ⬆️
cli/autostart.go 66.37% <0.00%> (-8.92%) ⬇️
cli/autostop.go 66.37% <0.00%> (-8.63%) ⬇️
peerbroker/dial.go 77.04% <0.00%> (-6.56%) ⬇️
site/src/components/Section/Section.tsx 61.11% <0.00%> (-5.56%) ⬇️
... and 32 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 64a8b4a...2ed4249. Read the comment docs.

@Emyrk Emyrk requested review from kylecarbs and f0ssel May 13, 2022 16:02
}

func (c *Client) userByIdentifier(ctx context.Context, ident string) (User, error) {
// UserByIdentifier returns a user for the username or uuid provided.
func (c *Client) UserByIdentifier(ctx context.Context, ident string) (User, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we change User to be this instead of creating a new handler? It seems like User is just wrong right now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For all /users/<param> routes, we could create a generic that accepts a string or UUID. Right now it's incorrectly stated that they require UUIDs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to make a generic, but unfortunately you cannot make struct methods generics 😢

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about changing User, then you have to do client.User(id.String()) because it can't take a uuid.
I can't even make it take a Stringer because string isn't a Stringer. I hit this trying to make it "generic" in some way, and kept falling short.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I'd rather just keep User with the UUID and add UserByUsername then. UserByIdentifier tells us very little about what the identifier is.

@Emyrk Emyrk requested a review from kylecarbs May 13, 2022 18:07
@ammario
Copy link
Member

ammario commented May 13, 2022

Thoughts on outdenting it to coder users activate <user> and coder users suspend <user>?

My thinking is status is a broad term and it's not immediately obvious it has to do with activation. For example, one may think it has to do with roles or email verification.

@Emyrk
Copy link
Member Author

Emyrk commented May 13, 2022

Thoughts on outdenting it to coder users activate <user> and coder users suspend <user>?

My thinking is status is a broad term and it's not immediately obvious it has to do with activation. For example, one may think it has to do with roles or email verification.

I'm cool with that. I had that originally, but don't have a strong opinion either way.

@misskniss misskniss added this to the V2 Beta milestone May 15, 2022
}

func (c *Client) userByIdentifier(ctx context.Context, ident string) (User, error) {
// UserByIdentifier returns a user for the username or uuid provided.
func (c *Client) UserByIdentifier(ctx context.Context, ident string) (User, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I'd rather just keep User with the UUID and add UserByUsername then. UserByIdentifier tells us very little about what the identifier is.

@Emyrk
Copy link
Member Author

Emyrk commented May 16, 2022

The annoying thing about UserByUsername and User, is that in the cli, it's easier to just take the input as is.

If we have User(id) and UserByUsername(name), then it feels weird to have the code pass the arg[0] which can be either a uuid, or a username.

The appropriate code would be to try and parse the arg as a uuid, and if it fails, try as a username. But the api already does that, and it seems excessive to check locally as well.


So having a function accept either is useful when just passing input along.

@kylecarbs
Copy link
Member

Fair enough. I don't think doing uuid.String() is bad. It represents what we do internally anyways. Having multiple methods that do the exact same thing seems worse.

@Emyrk
Copy link
Member Author

Emyrk commented May 16, 2022

Fair enough. I don't think doing uuid.String() is bad. It represents what we do internally anyways. Having multiple methods that do the exact same thing seems worse.

The nasty thing would be to accept an any and do a fmt.Sprint to get it's String(). Super annoying string does not implement Stringer

I'll use User(ctx, string) and call id.String() where used now

@Emyrk
Copy link
Member Author

Emyrk commented May 16, 2022

This is werid now client.User(cmd.Context(), codersdk.Me.String()). :(

@kylecarbs
Copy link
Member

We could just make codersdk.Me a string!

@misskniss misskniss modified the milestones: V2 Beta, Community MVP May 16, 2022
@misskniss misskniss removed the V2 BETA label May 16, 2022
@Emyrk Emyrk requested a review from kylecarbs May 16, 2022 20:22
Copy link
Member

@kylecarbs kylecarbs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. User changes are really nice!


// Prompt to confirm the action
_, err = cliui.Prompt(cmd, cliui.PromptOptions{
Text: fmt.Sprintf("Are you sure you want to %s this user?", verb),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use of this verb is really nice here!

@Emyrk Emyrk merged commit b55d83c into main May 16, 2022
@Emyrk Emyrk deleted the stevenmasley/user_cli_suspend_2 branch May 16, 2022 20:29
kylecarbs pushed a commit that referenced this pull request Jun 10, 2022
* feat: Add suspend/active user to cli
* UserID is now a string and allows for username too
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants