teams tab remove [options]
Removes a tab from the specified channel
| Option | Description |
| ----------------------- | ----------------------------------------- |
| -i, --teamId <teamId> | The ID of the team where the tab exists |
| -c, --channelId <channelId> | The ID of the channel to remove the tab from |
| -t, --tabId <tabId> | The ID of the tab to remove |
| --confirm | Don't prompt for confirmation |
Delate tab from channel - https://docs.microsoft.com/en-us/graph/api/teamstab-delete?view=graph-rest-1.0
I am happy to pick this up @garrytrinder
Also shouldn鈥檛 we add optional confirmation as well like all other commands?
We absolutely should. Good catch 馃憤馃徎
It鈥檚 all yours @rabwill thank you for your help 馃槉
Shall we also allow to specify the team, channel and tab by their names to save users from doing lookups first?
Nice one but I know our existing commands have only teamId in them e.g teams channel list so would this be a consistent option experience for users to have teamName? channelName has been used before so don't see an issue with that. If the spec can be updated. I can look into working on this. Ty
Got it. For now, let's stick with the current spec and use only ID. We can later extend all commands consistently to allow using both if there's a demand for it 馃憤
We can add --channelName and --tabName at a later date as @waldekmastykarz has mentioned as an enhancement.
The --teamName option is a little more involved as Teams allows you to create Teams with the same name, this is also the same for an Office 365 Group.
To ensure uniqueness we should consider using the mailNickname of the associated Office 365 Group, instead of displayName to identify a Team by name, as this is unique property, or throw an error if more than one group is found by name, if we decide to keep using displayName.
Awesome, so the spec is unchanged as of now and can be enhanced later. Nice. Will pick this up and work on it 馃檶馃徏 Thanks folks.
Most helpful comment
Got it. For now, let's stick with the current spec and use only ID. We can later extend all commands consistently to allow using both if there's a demand for it 馃憤