diff --git a/.github/maintainers_guide.md b/.github/maintainers_guide.md index c1f6a2223..622ed147c 100644 --- a/.github/maintainers_guide.md +++ b/.github/maintainers_guide.md @@ -19,7 +19,7 @@ You should also make sure you have the latest versions of `pip`, `setuptools`, ` On macOS, the easiest way to install these tools is by using [Homebrew](https://brew.sh/) and installing the `python` and `python3` packages. Some of the above packages are preinstalled and you can install the remaining on your own: -`pip install virtualenv wheel twine tox && pip3 install virtualenv twine tox`. +`pip install virtualenv wheel twine tox sphinx && pip3 install virtualenv twine tox sphinx`. ## Tasks @@ -40,15 +40,21 @@ You can generate the documentation by running `tox -e docs`. ### Releasing 1. Create the commit for the release: - * Bump the version number in adherence to [Semantic Versioning](http://semver.org/) in `slackclient/version.py`. - * Commit with a message including the new version number. For example `1.0.6`. + + - Bump the version number in adherence to [Semantic Versioning](http://semver.org/) in `slackclient/version.py`. + - Add a description of changes to the Changelog in `docs-src/changelog.rst` + - Build the docs with `./docs.sh`. + - Commit with a message including the new version number. For example `2.5.0`. + - Push the commit to a branch and create a PR to sanity check. + - Merge in release PR. + - Create a git tag for the release. For example `git tag 2.5.0`. + - Push the tag up to github with `git push origin --tags` 2. Distribute the release - * Build the distribtuions: `python setup.py sdist bdist_wheel`. This will create artifacts in the `dist` directory. - * Publish to PyPI: `twine upload dist/*`. You must have access to the credentials to publish. - * Create a GitHub Release. You will select the commit with updated version number (e.g. `1.0.6`) to assiociate with - the tag, and name the tag after this version (e.g. `1.0.6`). This will also serve as a Changelog for the project. - Add a description of changes to the Release. Mention Issue and PR #'s and @-mention contributors. + + - Build the distribtuions: `python setup.py sdist bdist_wheel --universal`. This will create artifacts in the `dist` directory. + - Publish to PyPI: `twine upload dist/*`. You must have access to the credentials to publish. + - Create a GitHub Release. You will select the commit with updated version number (e.g. `2.5.0`) to assiociate with the tag, and name the tag after this version (e.g. `2.5.0`). This will also serve as a Changelog for the project. Add a description of changes to the Release. Mention Issue and PR #'s and @-mention contributors. 3. (Slack Internal) Communicate the release internally. Include a link to the GitHub Release. @@ -75,18 +81,18 @@ versions. Labels are used to run issues through an organized workflow. Here are the basic definitions: -* `bug`: A confirmed bug report. A bug is considered confirmed when reproduction steps have been - documented and the issue has been reproduced. -* `enhancement`: A feature request for something this package might not already do. -* `docs`: An issue that is purely about documentation work. -* `tests`: An issue that is purely about testing work. -* `needs feedback`: An issue that may have claimed to be a bug but was not reproducible, or was otherwise missing some information. -* `discussion`: An issue that is purely meant to hold a discussion. Typically the maintainers are looking for feedback in this issues. -* `question`: An issue that is like a support request because the user's usage was not correct. -* `semver:major|minor|patch`: Metadata about how resolving this issue would affect the version number. -* `security`: An issue that has special consideration for security reasons. -* `good first contribution`: An issue that has a well-defined relatively-small scope, with clear expectations. It helps when the testing approach is also known. -* `duplicate`: An issue that is functionally the same as another issue. Apply this only if you've linked the other issue by number. +- `bug`: A confirmed bug report. A bug is considered confirmed when reproduction steps have been + documented and the issue has been reproduced. +- `enhancement`: A feature request for something this package might not already do. +- `docs`: An issue that is purely about documentation work. +- `tests`: An issue that is purely about testing work. +- `needs feedback`: An issue that may have claimed to be a bug but was not reproducible, or was otherwise missing some information. +- `discussion`: An issue that is purely meant to hold a discussion. Typically the maintainers are looking for feedback in this issues. +- `question`: An issue that is like a support request because the user's usage was not correct. +- `semver:major|minor|patch`: Metadata about how resolving this issue would affect the version number. +- `security`: An issue that has special consideration for security reasons. +- `good first contribution`: An issue that has a well-defined relatively-small scope, with clear expectations. It helps when the testing approach is also known. +- `duplicate`: An issue that is functionally the same as another issue. Apply this only if you've linked the other issue by number. **Triage** is the process of taking new issues that aren't yet "seen" and marking them with a basic level of information with labels. An issue should have **one** of the following labels applied: `bug`, `enhancement`, `question`, @@ -97,4 +103,4 @@ reopening is great and better than creating a duplicate issue. ## Everything else -When in doubt, find the other maintainers and ask. \ No newline at end of file +When in doubt, find the other maintainers and ask. diff --git a/docs-src/changelog.rst b/docs-src/changelog.rst index 0071d3b18..ce17a9a8f 100644 --- a/docs-src/changelog.rst +++ b/docs-src/changelog.rst @@ -2,6 +2,12 @@ Changelog ============================================== +v2.5.0 (2019-12-09) +------------------- +**New Features** + +1. [WebClient] Adding new oauth.v2.access Web API method. #577 + v2.4.0 (2019-11-27) ------------------- **New Features** diff --git a/docs/about.html b/docs/about.html index b6c2eeaec..145422d6c 100644 --- a/docs/about.html +++ b/docs/about.html @@ -162,6 +162,12 @@
If you intend for an app to be installed on multiple Slack workspaces, you will need to handle this installation via the industry-standard OAuth protocol. You can read more about how Slack handles Oauth.
+If you intend for an app to be installed on multiple Slack workspaces, you will need to handle this installation via the industry-standard OAuth protocoal. You can read more about how Slack handles Oauth.
(The OAuth exchange is facilitated via HTTP and requires a webserver; in this example, we’ll use Flask.)
To configure your app for OAuth, you’ll need a client ID, a client secret, and a set of one or more scopes that will be applied to the token once it is granted. The client ID and client secret are available from your app’s configuration page. The scopes are determined by the functionality of the app – every method you wish to access has a corresponding scope and your app will need to request that scope in order to be able to access the method. Review Slack’s full list of OAuth scopes.
import os
@@ -261,14 +267,14 @@ Multiple Workspace Installhttps://slack.com/oauth/authorize with scope
and client_id
query parameters, or you can use our pre-built Add to Slack button to do all the work for you.
This link directs the user to Slack’s OAuth acceptance page, where the user will review and accept or refuse the permissions your app is requesting as defined by the scope(s).
-@app.route("/begin_auth", methods=["GET"])
+@app.route("/begin_auth", methods=["GET"])
def pre_install():
- return f'<a href="https://slack.com/oauth/authorize?scope={ oauth_scope }&client_id={ client_id }">Add to Slack</a>'
+ return f'<a href="https://slack.com/oauth/authorize?scope={ oauth_scope }&client_id={ client_id }">Add to Slack</a>'
The OAuth completion page
Once the user has agreed to the permissions you’ve requested, Slack will redirect the user to your auth completion page, which includes a code
query string param. You’ll use the code
param to call the oauth.access
endpoint that will finally grant you the token.
-