add subcomand admin #161

Open
opened 2020-07-19 15:08:52 +00:00 by 6543 · 7 comments
Owner

add a subcomand named admin witch with features like:

  • create/edit/delete users
  • list all users/orgs/repos
  • ... and what the admin api will provide in the future
add a subcomand named admin witch with features like: * create/edit/delete users * list all users/orgs/repos * ... and what the admin api will provide in the future
6543 added the
kind
feature
label 2020-07-19 15:09:16 +00:00
6543 added this to the v0.5.0 milestone 2020-07-19 15:09:21 +00:00
Member

important use case: add users to org teams

important use case: add users to org teams
6543 modified the milestone from v0.5.0 to v0.6.0 2020-09-14 01:22:24 +00:00
Member

I just want to know if the following would go into the right direction how the commands / sub commands should be structured: (based on the README I use the plural form whereas the singular should be handled via aliases):

  • tea admin users ...
tea admin users create 
tea admin users ls
tea admin users edit
tea admin users delete
  • tea admin organizations ...
tea admin organizations create 
tea admin organizations edit
tea admin organizations ls
tea admin organizations delete
  • tea admin teams ...
    The relationship to the appropriate organizations can be done via an option like --owner <name>:
tea admin teams create   <team>
tea admin teams edit     <team>
tea admin teams ls
tea admin teams delete   <team>

Now the question how to handle add/remove of users to appropriate orga?

tea admin teams add      --owner <team> <username>
tea admin teams remove   --owner <team> <username>

Alternative via positional arguments? like:

tea admin teams add      <team> <username>
tea admin teams remove   <team> <username>

(The existing command seemed to be going via --owner .. way)...

  • tea admin repos ...
    The relationship to the appropriate organizations can be done via an option like --owner <name>:
tea admin repos create 
tea admin repos edit
tea admin repos ls
tea admin repos delete
I just want to know if the following would go into the right direction how the commands / sub commands should be structured: (based on the README I use the plural form whereas the singular should be handled via aliases): * `tea admin users ...` ``` tea admin users create tea admin users ls tea admin users edit tea admin users delete ``` * `tea admin organizations ...` ``` tea admin organizations create tea admin organizations edit tea admin organizations ls tea admin organizations delete ``` * `tea admin teams ...` The relationship to the appropriate organizations can be done via an option like `--owner <name>`: ``` tea admin teams create <team> tea admin teams edit <team> tea admin teams ls tea admin teams delete <team> ``` Now the question how to handle add/remove of users to appropriate `orga`? ``` tea admin teams add --owner <team> <username> tea admin teams remove --owner <team> <username> ``` Alternative via positional arguments? like: ``` tea admin teams add <team> <username> tea admin teams remove <team> <username> ``` (The existing command seemed to be going via `--owner ..` way)... * `tea admin repos ...` The relationship to the appropriate organizations can be done via an option like `--owner <name>`: ``` tea admin repos create tea admin repos edit tea admin repos ls tea admin repos delete ```
Member

I have started to create a basic foundation for the `admin´ commands https://gitea.com/khmarbaise/tea/src/branch/issue-161-admin-command (I don't want to make a PR of it yet because I'm not sure if the approache is the right way)...

I just want to know if this is the direction we could go?

Further acting would be to start with a pr for the foundation admin commands
and add several separate PR's for the implementation of each sub command...

I have started to create a basic foundation for the `admin´ commands https://gitea.com/khmarbaise/tea/src/branch/issue-161-admin-command (I don't want to make a PR of it yet because I'm not sure if the approache is the right way)... I just want to know if this is the direction we could go? Further acting would be to start with a pr for the foundation admin commands and add several separate PR's for the implementation of each sub command...
Author
Owner

admin subcomand is in one way special: we have to make sure the current user is an admin befor we do anthing more

admin subcomand is in one way special: we have to make sure the current user is an admin befor we do anthing more
6543 modified the milestone from v0.6.0 to v0.7.0 2020-12-07 01:25:09 +00:00
Author
Owner

moved new subcomand into new milestone, like to release v0.6.0 within december

so we should finish the "big refactor" & polish added feature + bugfixing ;)

@khmarbaise @noerw

moved new subcomand into new milestone, like to release v0.6.0 within december so we should finish the "big refactor" & polish added feature + bugfixing ;) @khmarbaise @noerw
6543 modified the milestone from v0.7.0 to v0.8.0 2021-03-05 11:58:50 +00:00
Member

I've started some automation via the /teams API endpoint to automatically add new users to certain orgs.

Would be awesome if this could be supported via tea ?

I've started some automation via the `/teams` API endpoint to automatically add new users to certain orgs. Would be awesome if this could be supported via `tea` ?
Author
Owner

@pat-s

I've started some automation via the /teams API endpoint to automatically add new users to certain orgs.

Would be awesome if this could be supported via tea ?

nice idear, i wont have time to add it, but I'm happy to test and review pulls ;)

@pat-s >I've started some automation via the `/teams` API endpoint to automatically add new users to certain orgs. > >Would be awesome if this could be supported via `tea` ? nice idear, i wont have time to add it, but I'm happy to test and review pulls ;)
6543 modified the milestone from v0.8.0 to v0.9.0 2021-08-16 12:54:56 +00:00
noerw modified the milestone from v0.9.0 to v0.10.0 2022-09-13 18:04:59 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/tea#161
No description provided.