Cli-microsoft365: Enhancement: return information about newly created team

Created on 15 Jun 2020  路  5Comments  路  Source: pnp/cli-microsoft365

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.

enhancement feature request good first issue work in progress

Most helpful comment

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.

All 5 comments

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": "[email protected]",
  "mailEnabled": true,
  "mailNickname": "golfassist",
  "membershipRule": null,
  "membershipRuleProcessingState": null,
  "onPremisesLastSyncDateTime": null,
  "onPremisesSecurityIdentifier": null,
  "onPremisesSyncEnabled": null,
  "preferredDataLocation": "CAN",
  "preferredLanguage": null,
  "proxyAddresses": [
      "smtp:[email protected]",
      "SMTP:[email protected]"
  ],
  "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?

@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

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).

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

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.

Was this page helpful?
0 / 5 - 0 ratings