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

Add Support for App Manifest Endpoints (apps.manifest.*) #1123

Merged

Conversation

misscoded
Copy link
Contributor

Summary

Fixes #1119

This pull request introduces support for the App Manifest endpoints, including:

apps.manifest.create
apps.manifest.delete
apps.manifest.export
apps.manifest.update
apps.manifest.validate
tooling.tokens.rotate

Category (place an x in each of the [ ])

  • slack_sdk.web.WebClient (sync/async) (Web API client)
  • slack_sdk.webhook.WebhookClient (sync/async) (Incoming Webhook, response_url sender)
  • slack_sdk.socket_mode (Socket Mode client)
  • slack_sdk.signature (Request Signature Verifier)
  • slack_sdk.oauth (OAuth Flow Utilities)
  • slack_sdk.models (UI component builders)
  • slack_sdk.scim (SCIM API client)
  • slack_sdk.audit_logs (Audit Logs API client)
  • slack_sdk.rtm_v2 (RTM client)
  • /docs-src (Documents, have you run ./scripts/docs.sh?)
  • /docs-src-v2 (Documents, have you run ./scripts/docs-v2.sh?)
  • /tutorial (PythOnBoardingBot tutorial)
  • tests/integration_tests (Automated tests for this library)

Requirements (place an x in each [ ])

  • I've read and understood the Contributing Guidelines and have done my best effort to follow them.
  • I've read and agree to the Code of Conduct.
  • I've run python3 -m venv .venv && source .venv/bin/activate && ./scripts/run_validation.sh after making the changes.

@misscoded misscoded added enhancement M-T: A feature request for new functionality web-client labels Oct 6, 2021
@misscoded misscoded requested a review from seratch October 6, 2021 05:19
@@ -15,7 +15,7 @@


class TestWebClientCoverage(unittest.TestCase):
# 240 endpoints as of Sept 4, 2021
# 240 endpoints as of Sept 4, 2021 // TODO :: update before merge
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since this relies on the publicly accessible methods, not sure how this is to be changed (or not)

Copy link
Member

Choose a reason for hiding this comment

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

You can manually add the new elements to all_api_methods in the following line of code with a TODO comment saying # TODO: we will delete this once the APIs are publicly available.

@@ -366,6 +366,23 @@ async def run_method(self, method_name, method, async_method):
method(client_id="111.222", client_secret="xxx")["method"]
)
await async_method(client_id="111.222", client_secret="xxx")
elif method_name == "apps_manifest_create":
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've always had issues with running tests locally, but the ones currently failing either are websockets or sqlite3 related. Can debug further tomorrow, but would appreciate any guidance on how to ensure all is well.

Copy link
Member

Choose a reason for hiding this comment

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

For the sqlite3 errors, perhaps your local environment has an old version of file based databases. You can delete logs/*.db files to fix the errors. I'm not sure about the error with websockets package but you can try running tests using the scripts under scripts directory after setting up a plain python venv (python 3 -m venv .venv && source .venv/bin/activate).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Your suggestion resolved the issues I was having. Thank you!

@seratch
Copy link
Member

seratch commented Oct 6, 2021

@misscoded I just adjusted the GH Actions settings to enable CI builds for PRs toward feat- branches. Can you rebase onto the latest main revision? 0045b5d

@codecov
Copy link

codecov bot commented Oct 6, 2021

Codecov Report

Merging #1123 (af2ba93) into feat-app-manifests (0045b5d) will increase coverage by 0.05%.
The diff coverage is 100.00%.

Impacted file tree graph

@@                  Coverage Diff                   @@
##           feat-app-manifests    #1123      +/-   ##
======================================================
+ Coverage               88.05%   88.10%   +0.05%     
======================================================
  Files                     110      110              
  Lines                   10681    10735      +54     
======================================================
+ Hits                     9405     9458      +53     
- Misses                   1276     1277       +1     
Impacted Files Coverage Δ
slack_sdk/web/async_client.py 90.16% <100.00%> (+0.18%) ⬆️
slack_sdk/web/client.py 91.57% <100.00%> (+0.15%) ⬆️
slack_sdk/web/legacy_client.py 91.17% <100.00%> (+0.16%) ⬆️
slack_sdk/socket_mode/builtin/internals.py 70.85% <0.00%> (-0.45%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0045b5d...af2ba93. Read the comment docs.

async def apps_manifest_create(
self,
*,
manifest: str,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@seratch I want to verify I've crafted these signatures correctly. For testing purposes (and as I mentioned in the corresponding PR), I used the following:

client.apps_manifest_create(token=CONFIGURATION_ACCESS_TOKEN, manifest=VALID_APP_MANIFEST)

Again, since these tokens are so specific to this set of methods, I assume the explicit passing of the tooling token will be often utilized. Does anything need to change about the arguments to encourage this, or is what is here fine?

Copy link
Member

Choose a reason for hiding this comment

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

First of all, for all methods except api.test, token argument is available as part of kwargs. The current code works as-is.

For apps.connections.open API method, we added app_token this way for consistency with Node SDK. We may want to have something similar for tooling tokens but I think that it's not really necessary so far.

Speaking of realistic use cases, I don't think developers often want to use bot token along with tooling token in a single WebClient instance. When using apps.manifest.* endpoints, it's rare to reuse a WebClient associated with a specific workspace installation (except the case where you would like to send manifest via an existing Slack app; I don't think this is a common use case). For this reason, I think the current code should be fine.

If many people think explicit name of the argument should exist here and we receive such feedback a lot, we may revisit, though.

Copy link
Member

@seratch seratch left a comment

Choose a reason for hiding this comment

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

Looks good me (I may add integration tests later but it's okay not to have it so far). You can merge this PR if you squash commits into one in advance (or using the button to squash commits).

async def apps_manifest_create(
self,
*,
manifest: str,
Copy link
Member

Choose a reason for hiding this comment

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

First of all, for all methods except api.test, token argument is available as part of kwargs. The current code works as-is.

For apps.connections.open API method, we added app_token this way for consistency with Node SDK. We may want to have something similar for tooling tokens but I think that it's not really necessary so far.

Speaking of realistic use cases, I don't think developers often want to use bot token along with tooling token in a single WebClient instance. When using apps.manifest.* endpoints, it's rare to reuse a WebClient associated with a specific workspace installation (except the case where you would like to send manifest via an existing Slack app; I don't think this is a common use case). For this reason, I think the current code should be fine.

If many people think explicit name of the argument should exist here and we receive such feedback a lot, we may revisit, though.

@AntonVanGoethem
Copy link

Hi everyone, awesome that you are adding support for this! Any idea on when it would be merged? I'm planning on using it to automagically change for example the slash command url with the latest ngrok link for local development. Will this be possible? The only thing I don't understand yet are the access tokens, they seems to only be valid for 12 hours? Thanks so much!

@misscoded misscoded merged commit 441ed5e into slackapi:feat-app-manifests Oct 8, 2021
@misscoded
Copy link
Contributor Author

Hi @AntonVanGoethem -- love that you're excited about this new functionality! Your use case sounds compelling, and though I've never tried it myself, I don't see why it wouldn't be possible.

In terms of availability, as this feature is still in beta, we'll be cutting a dedicated beta release here shortly, so stay tuned. 🙂

In the meantime, if you'd like to learn more about access tokens, I'd recommend checking out the documentation on these new app configuration tokens. I can confirm that they do expire after 12 hours, at which point (or ideally before) you need to refresh the token. To refresh config tokens, a call can be made to tooling.tokens.rotate, using the corresponding refresh token as an argument.

Hope this helps!

@AntonVanGoethem
Copy link

Okay, thanks a lot!

@seratch seratch added this to the 3.x milestone Oct 17, 2021
Copy link

@BeRT2me BeRT2me left a comment

Choose a reason for hiding this comment

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

Any updates on this "beta release"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement M-T: A feature request for new functionality web-client
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants