RESP-4311: Update forked slack go library #33
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nel to close when it is finished, and consumer to see the close
…outer goroutine did not wait on all inner goroutines that had a chance to set it, also make sure to check error for context.Canceled appropriately
…l via a method that has an escape hatch; unable to change public Events field without breaking api, though
… when getting buffered (first) error
…ntexts for channel ops, though they are very similar now
…her small changes
Co-authored-by: Naoki Kanatani <[email protected]>
…erError Co-authored-by: Naoki Kanatani <[email protected]>
…modehandler will react on context cancellation
This is something that Slack returns by default on API response.
Signed-off-by: Ivan Milchev <[email protected]>
add 2FA type to slack user
…in-ci Test with Go 1.18~1.20
add support for user_profile_changed callback event
Update README for slacktest
Export the Binder type in slacktest
The code changes in this commit add support for parsing AppRateLimited events in the `ParseEvent` function. This allows the application to handle rate-limited events from the Slack API.
* Add Properties.Canvas to Channel * Trigger GitHub Actions --------- Co-authored-by: Lorenzo Aiello <[email protected]>
* fix: create multipart form when multipart request * call createFormFields in go func() del coment * Trigger GitHub Actions --------- Co-authored-by: Lorenzo Aiello <[email protected]>
Support publishing a messge to a specific thread https://api.slack.com/interactivity/handling#publishing_in_thread From slack interactivity documentation: Publishing responses in thread If you want to publish a message to a specific thread, you'll need to include an attribute response_type and set its value to in_channel. Then, to specify the thread, include a thread_ts. Also, be sure to set replace_original to false or you'll overwrite the message you're wanting to respond to!
) As per [block kit docs](https://api.slack.com/reference/block-kit/blocks#date-element-type), the date element requires a format string to be included. Currently, submitting a block kit with this element results in a slack API error. Also added the two optional fields `url` and `fallback` for posterity. ##### PR preparation Run `make pr-prep` from the root of the repository to run formatting, linting and tests. ##### Should this be an issue instead - [ ] is it a convenience method? (no new functionality, streamlines some use case) - [ ] exposes a previously private type, const, method, etc. - [ ] is it application specific (caching, retry logic, rate limiting, etc) - [ ] is it performance related. ##### API changes Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes. - no tests, if you're adding to the API include at least a single test of the happy case. - If you can accomplish your goal without changing the API, then do so. - dependency changes. updates are okay. adding/removing need justification. ###### Examples of API changes that do not meet guidelines: - in library cache for users. caches are use case specific. - Convenience methods for Sending Messages, update, post, ephemeral, etc. consider opening an issue instead.
…go#1320) ##### Pull Request Guidelines These are recommendations for pull requests. They are strictly guidelines to help manage expectations. ##### PR preparation Run `make pr-prep` from the root of the repository to run formatting, linting and tests. ##### Should this be an issue instead - [x] is it a convenience method? (no new functionality, streamlines some use case) - [ ] exposes a previously private type, const, method, etc. - [ ] is it application specific (caching, retry logic, rate limiting, etc) - [ ] is it performance related. Fix for [issue slack-go#1276](slack-go#1276) Updated the datatype of RichTextInputBlockElement InitialValue from string to *RichTextBlock
…ocks (slack-go#1319) This PR adds support for the `unicode` parameter to the `RichTextSectionEmojiElement` struct for rich text blocks. While this parameter is not officially documented in Slack's API, it is present in the JSON payload of actual Slack messages and represents the Unicode code point of the emoji. https://api.slack.com/reference/block-kit/blocks#emoji-element-type For example, a rich text block with an emoji can include the unicode field like this: ```json "blocks": [ { "type": "rich_text", "block_id": "xxxxx", "elements": [ { "type": "rich_text_section", "elements": [ { "type": "emoji", "name": "+1", "unicode": "1f44d" } ] } ] } ] ``` The unicode parameter behaves similarly to the skin-tone parameter, which is also undocumented but has already been included in the structure. This PR aligns the handling of unicode in the same way to ensure emojis are fully supported in Slack message payloads. Please review, and feel free to provide feedback if any adjustments are needed. Thank you! ##### Pull Request Guidelines These are recommendations for pull requests. They are strictly guidelines to help manage expectations. ##### PR preparation Run `make pr-prep` from the root of the repository to run formatting, linting and tests. ##### Should this be an issue instead - [ ] is it a convenience method? (no new functionality, streamlines some use case) - [ ] exposes a previously private type, const, method, etc. - [ ] is it application specific (caching, retry logic, rate limiting, etc) - [ ] is it performance related. ##### API changes Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes. - no tests, if you're adding to the API include at least a single test of the happy case. - If you can accomplish your goal without changing the API, then do so. - dependency changes. updates are okay. adding/removing need justification. ###### Examples of API changes that do not meet guidelines: - in library cache for users. caches are use case specific. - Convenience methods for Sending Messages, update, post, ephemeral, etc. consider opening an issue instead.
…go#1190) Implement the API methods for the Calls API in Slack https://api.slack.com/apis/calls Implemented methods - `calls.add` - Indicate a new call has been started - `calls.end` - Indicate to slack that the call has ended - `calls.info` - Get information about an ongoing slack call object - `calls.update` - update call information - `calls.participants.add` - `calls.participants.remove` Additionally, I've added the minimal version of `Block{Type: "call", CallID: string}` which slack recommends/requires be posted back to the channel https://api.slack.com/apis/calls#post_to_channel. All implemented functionality is publicly documented. There appear to be additional attributes on the `type: call` block, however those appear to be internal values for slack's rendering, so I have left them out. See this gist for specific responses https://gist.github.com/winston-stripe/0cac608bd63b42d73a352be53577f7fd ##### Pull Request Guidelines These are recommendations for pull requests. They are strictly guidelines to help manage expectations. ##### PR preparation Run `make pr-prep` from the root of the repository to run formatting, linting and tests. ##### Should this be an issue instead - [ ] is it a convenience method? (no new functionality, streamlines some use case) - [ ] exposes a previously private type, const, method, etc. - [ ] is it application specific (caching, retry logic, rate limiting, etc) - [ ] is it performance related. ##### API changes Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes. - no tests, if you're adding to the API include at least a single test of the happy case. - If you can accomplish your goal without changing the API, then do so. - dependency changes. updates are okay. adding/removing need justification. ###### Examples of API changes that do not meet guidelines: - in library cache for users. caches are use case specific. - Convenience methods for Sending Messages, update, post, ephemeral, etc. consider opening an issue instead. --------- Co-authored-by: Winston Durand <[email protected]>
Adds some convenience methods to block elements to easily add functionality --------- Co-authored-by: Lorenzo Aiello <[email protected]>
…k-go#1328) Completion of slack-go#1301 - Adds the new complete functions for the Function Execution Event - Adds the context version of those methods --- > this PR to handle event [function_executed](https://api.slack.com/events/function_executed) and response the function with [functions.completeSuccess](https://api.slack.com/methods/functions.completeSuccess) and [functions.completeError](https://api.slack.com/methods/functions.completeError) --------- Co-authored-by: Yoga Setiawan <[email protected]>
…go#1330) Expose the ability to override the [external_limited option](https://api.slack.com/methods/conversations.inviteShared#arg_external_limited) for inviteShared. Adding the param to all the InviteSharedEmailsToConversation, etc. methods would be a breaking change to those callers, so I opted instead to expose the underlying helper (renamed to InviteSharedToConversation). I feel like the convenience methods (InviteSharedEmailsToConversation/InviteSharedUserIDsToConversation) are not actually that much more convenient than just using the helper, and I think we can eventually remove them in favor of having people call InviteSharedToConversation directly. But that's a future thing. Although it's slightly inconvenient for the caller to use *bool for ExternalLimited, the two alternatives I considered are, I think worse: - Include ExternalLimited as a bool in the InviteSharedParams. I dislike this way because it gives the SDK user of InviteSharedToConversation a different default behavior from inviteShared, since the default value in the API is true. - Add a bool like NonExternalLimited to InviteSharedParams. This way the defaulting is consistent with the API if it's not specified; however, the InviteSharedParams no longer mirror the API args, which I think is confusing.
This PR introduces new functionalities for managing canvases and creating channel-specific canvases. - CreateCanvas - DeleteCanvas - EditCanvas - SetCanvasAccess - DeleteCanvasAccess - LookupCanvasSections - CreateChannelCanvas Closes slack-go#1333
…update-forked-slack-go-library
kelseymills
commented
Nov 5, 2024
There was a problem hiding this comment.
This file had conflicts because UserChangeEvent is slightly different, have changed to their version
kelseymills
force-pushed
the
kelsey/resp-4311-update-forked-slack-go-library
branch
from
f610138 to
1e4725e
Compare
kelseymills
force-pushed
the
kelsey/resp-4311-update-forked-slack-go-library
branch
from
fc8593a to
0c1f7fe
Compare
kelseymills
force-pushed
the
kelsey/resp-4311-update-forked-slack-go-library
branch
from
2ce6284 to
3601e01
Compare
kelseymills
force-pushed
the
kelsey/resp-4311-update-forked-slack-go-library
branch
from
bfa47f0 to
85a6fc8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Syncing our branch of slack-go with upstream 🐘
Most of the changes are just adding new code they've added there. I've highlighted all the places I had to resolve conflicts with our changes, all of which were us adding a feature ahead of them, and them implementing it slightly differently.
I've commented on the files I've updated so you don't waste time reviewing 98 files on non-conflicting changes from upstream.
Notable changes:
RichTextElementGenericSectionso that we can continue to generalise the three types of section element in our codebaseNote: these changes won't come into effect in core until the PR where I bump the version there, and that will have a couple of tiny changes but they're very minimal. I will have that ready and tested before merging this.