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

Enhancement: return information about newly created team #1654

Closed
waldekmastykarz opened this issue Jun 15, 2020 · 5 comments
Closed

Enhancement: return information about newly created team #1654

waldekmastykarz opened this issue Jun 15, 2020 · 5 comments

Comments

@waldekmastykarz
Copy link
Member

Related to #1652

After creating a team, we should return the information about that team returned by the API so that it can be used for subsequent operations.

@garrytrinder
Copy link
Member

In the case of the teams team add command, as it returns a teamsAsyncOperation operation response, we won't be able to return the full team object until the operation has completed.

I see that we have a couple of options

  1. Remove the --wait option and make this the default behaviour, we can then make an additional call to return either the true team object, or group object for that team.
{
  "isArchived" : false,
  "memberSettings": {
    "allowCreateUpdateChannels": true,
    "allowDeleteChannels": true,
    "allowAddRemoveApps": true,
    "allowCreateUpdateRemoveTabs": true,
    "allowCreateUpdateRemoveConnectors": true    
  },
  "guestSettings": {
    "allowCreateUpdateChannels": true,
    "allowDeleteChannels": true 
  },
  "messagingSettings": {
    "allowUserEditMessages": true,
    "allowUserDeleteMessages": true,
    "allowOwnerDeleteMessages": true,
    "allowTeamMentions": true,
    "allowChannelMentions": true    
  },
  "funSettings": {
    "allowGiphy": true,
    "giphyContentRating": "strict",
    "allowStickersAndMemes": true,
    "allowCustomMemes": true
  },
  "discoverySettings": {
    "showInTeamsSearchAndSuggestions": true
  }
}

Source: https://docs.microsoft.com/en-gb/graph/api/team-get?view=graph-rest-beta&tabs=http

{
  "id": "45b7d2e7-b882-4a80-ba97-10b7a63b8fa4",
  "deletedDateTime": null,
  "classification": null,
  "createdDateTime": "2018-12-22T02:21:05Z",
  "description": "Self help community for golf",
  "displayName": "Golf Assist",
  "expirationDateTime": null,
  "groupTypes": [
      "Unified"
  ],
  "mail": "golfassist@contoso.com",
  "mailEnabled": true,
  "mailNickname": "golfassist",
  "membershipRule": null,
  "membershipRuleProcessingState": null,
  "onPremisesLastSyncDateTime": null,
  "onPremisesSecurityIdentifier": null,
  "onPremisesSyncEnabled": null,
  "preferredDataLocation": "CAN",
  "preferredLanguage": null,
  "proxyAddresses": [
      "smtp:golfassist@contoso.onmicrosoft.com",
      "SMTP:golfassist@contoso.com"
  ],
  "renewedDateTime": "2018-12-22T02:21:05Z",
  "resourceBehaviorOptions": [],
  "resourceProvisioningOptions": [],
  "securityEnabled": false,
  "theme": null,
  "visibility": "Public",
  "onPremisesProvisioningErrors": []
}

Source: https://docs.microsoft.com/en-gb/graph/api/group-get?view=graph-rest-beta&tabs=http

or

  1. Return the teamsAsyncOperation response containing the teamId in the targetResourceId property when the command has completed, so we have the same behaviour with or without the --wait option.
{
    "id": "string",
    "operationType": "archiveTeam",
    "createdDateTime": "2018-01-01T00:00:00.0000000Z",
    "status": "succeeded",
    "lastActionDateTime": "2018-01-01T00:00:00.0000000Z",
    "attemptsCount": 1,
    "targetResourceId": "fa4aa5a2-a75b-4769-86f4-9e2742a18fda",
    "targetResourceLocation": "/groups('fa4aa5a2-a75b-4769-86f4-9e2742a18fda')/team",
    "error": null
}

Source: https://docs.microsoft.com/en-us/graph/api/resources/teamsasyncoperation?view=graph-rest-beta

@waldekmastykarz @harp365 thoughts?

@harp365
Copy link

harp365 commented Jun 15, 2020

@garrytrinder Part of me wants to say go for the bake in the wait operation and get the full set of created Team info back, however thinking on it some more. I feel that the Id is the key and I suppose it would be nice perhaps not for me but others if they are doing this as part of a script and the rest of the script does not depend on the Team being in place to have the option to not wait. As once the Id has been obtained it would not be too much of a job to make a call to get the full information if needed.

So that is a long winded way of me saying option two for me, as I think the ability to not wait might be desirable for some. Albeit personally I would happily wait just to know something has well and truly happened before moving along.

Thanks

@waldekmastykarz
Copy link
Member Author

What if we used different output depending if you used wait or not? If you use wait, you get the group object back (I think it's more valuable then the team object, right?). If you don't use wait, you get the job info which you can use yourself to check if the team has been created (assuming you even care about it).

@harp365
Copy link

harp365 commented Jun 15, 2020

I mean at its core it is a group, so the group object would certainly still serve my purpose.

@garrytrinder
Copy link
Member

What if we used different output depending if you used wait or not? If you use wait, you get the group object back (I think it's more valuable then the team object, right?). If you don't use wait, you get the job info which you can use yourself to check if the team has been created (assuming you even care about it).

Sounds like a plan, we should add a note into the docs to let users know of the difference in responses based on the presence of the --wait option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment