Skip to content

Conversation

@carlosscastro
Copy link
Contributor

@carlosscastro carlosscastro commented Apr 2, 2018

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.

PR information

  • The title of the PR is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
  • Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
  • If applicable, the PR references the bug/issue that it fixes.
  • Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

@AutorestCI
Copy link

AutorestCI commented Apr 2, 2018

Automation for azure-sdk-for-go

A PR has been created for you:
Azure/azure-sdk-for-go#1588

@AutorestCI
Copy link

AutorestCI commented Apr 2, 2018

Automation for azure-sdk-for-python

A PR has been created for you based on this PR content.

Once this PR will be merged, content will be added to your service PR:
Azure/azure-sdk-for-python#2337

@AutorestCI
Copy link

AutorestCI commented Apr 2, 2018

Automation for azure-libraries-for-java

Nothing to generate for azure-libraries-for-java

@AutorestCI
Copy link

AutorestCI commented Apr 2, 2018

Automation for azure-sdk-for-node

Nothing to generate for azure-sdk-for-node

@carlosscastro
Copy link
Contributor Author

The goal of this pull request is mainly to introduce Channels, which are different means to expose a bot. Given that a bot resource has multiple channels, we have modeled the channels as a nested (and proxy only) resource of the bot.

We have multiple channels where bots can be exposed, and each has a different payload, but there is common information and machinery across channels as well.

This is why we modeled channels the following way

/botservice/{botid}/channel/{channelid}

Where channel id specifies the type of the channel, such as Facebook, Email or Skype. In the swagger , given that each channel has a specific payload, we create a base class channel and then inherited classes, making use of the "discriminator" feature of swagger.

@olydis olydis assigned olydis and unassigned marstr Apr 2, 2018
@olydis
Copy link
Contributor

olydis commented Apr 2, 2018

@marstr Stole this from you since I got assigned to the original PR in private, just moved this over to public 🙂

@olydis
Copy link
Contributor

olydis commented Apr 2, 2018

@carlosscastro Awesome, thanks for moving this over! 🙂

@olydis olydis added the WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required label Apr 2, 2018
@olydis
Copy link
Contributor

olydis commented Apr 2, 2018

@ravbhatnagar New operations (anything starting with Channels_ - I'd just look at the incoming file, the diff is messed up in the operations area...) and types DirectLineSite, WebChatSite and all types containing Channel.

Note that the diff formally indicates breaking changes (e.g. changed path of "check name availability" operation), but there are none: The RP went public as represented by the Swagger after this PR and no SDKs have been released based on the "old" Swagger. I've only migrated the old Swagger from private to public in order to accept this PR against public.

"type": "string",
"description": "Facebook application secret"
},
"accessToken": {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this a secret? If yes, it should not be returned via a GET

"type": "string",
"description": "Facebook application id"
},
"appSecret": {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this a secret? If yes, it should not be returned via a GET

"readOnly": true,
"description": "Callback Url"
},
"isEnabled": {
Copy link
Contributor

Choose a reason for hiding this comment

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

bools are typically not recommended. Not self descriptive and dont allow for future expansion of values that can be supported. Consider - channelState or channelStatus - Enabled|Disabled and in future it can potentially support more values.

"type": "string",
"description": "The email address"
},
"password": {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should not be returned via a GET/PUT. It should be exposed via POST if needed.

Copy link
Contributor

Choose a reason for hiding this comment

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

same feedback for all other such properties in different models.

@olydis
Copy link
Contributor

olydis commented Apr 11, 2018

@carlosscastro please address the feedback, otherwise this PR will be closed due to inactivity (but can of course be reopened at a later point in time).

@olydis olydis assigned salameer and unassigned olydis Apr 13, 2018
@olydis
Copy link
Contributor

olydis commented Apr 13, 2018

@salameer @carlosscastro Closing due to inactivity. Feel free to reopen once you are ready to address the feedback.

@carlosscastro
Copy link
Contributor Author

Thanks! I was waiting for a response from Gaurav regarding the right soluiton to his comments.

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

Labels

WaitForARMFeedback <valid label in PR review process> add this label when ARM review is required

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants