feat: merge latest #1
Open
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
Update workflow for testing
Add metadata related event types
Handle the NULL value, when API returns "timestamp": null
fix: UploadFileContext not calling api.AuthTestContext
Handle possible null in JSONTime Unmarshal.
Honor deadman timer, fixes #1093
sharedLinks struct should be exported
Deserialize file events
Add support for status_emoji_display_info
fix: remove omitempty from replace_original and delete_orginal
Fix WorkflowStepCompletedRequest options handling
…sations-replies-api add include_all_metadata to conversations.replies API
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.
##### 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 #1276](slack-go/slack#1276) Updated the datatype of RichTextInputBlockElement InitialValue from string to *RichTextBlock
…ocks (#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.
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]>
Completion of slack-go/slack#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]>
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 #1333
Added new function for Slack AI & Assistants, information can be found here: https://api.slack.com/docs/apps/ai New Events: https://api.slack.com/events/assistant_thread_started https://api.slack.com/events/assistant_thread_context_changed New API Calls: https://api.slack.com/methods/assistant.threads.setStatus https://api.slack.com/methods/assistant.threads.setSuggestedPrompts https://api.slack.com/methods/assistant.threads.setTitle Tests have been added and pass all checks via `make pr-prep`.
This is a fix for [PR 1331](slack-go/slack#1331), which I mistakenly removed the channel_id parameter from the API request during feedback. Without channel_id provided, the call always returns `invalid_arguments`.
In a rich text `emoji` element, the `skin_tone` value is optional, and when not provided will use the default skin tone. When unmarshalling from JSON, this parameter defaults to an invalid value of 0 (`skin_tone` values range from 2 to 6), resulting in an "invalid_blocks" error when sending a message. This PR allows the `skin_tone` element to be omitted when unmarshalling from JSON.
I'd like to introduce the fix for `ScheduledMessage` API. Currently, it doesn't return scheduled_message_id where this ID is needed for cancelling the scheduled message. My change is the least intrusive I could think of. It doesn't introduce any new field or adding new API. Basically, this change should be backward compatible. It is based on the fact that the API [chat.postMessage](https://api.slack.com/methods/chat.postMessage#examples) doesn't return `scheduled_message_id` and the API [chat.scheduledMessage](https://api.slack.com/methods/chat.scheduleMessage#examples) doesn't return either `message.ts` or `ts`. We just need to check the presence of this field and determine the caller API based on that. Existing code shouldn't break because the `timestamp` is always an empty string for `ScheduledMessage` API. Now it will return `scheduled_message_id` in place of `timestamp`. `SendMessage` should remain the same. ##### 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.
This pull request introduces a Contributing Guide to start codifying best practices and norms in the project. It also eliminates two old files that can be safely removed and just retained in the git history. The notable items in the contributing guide are: - Go Comment Formatting (already largely in place) - Codifying a preference for Input/Output structs on functions to allow more non-breaking changes to function calls as parameters change/expand over time (things have already been trending in this direction, but it helps to commit to the direction) I'll leave this up for a bit in case anyone has any thoughts or feedback.
Resolving issue slack-go/slack#1352 that currently unable to parse the host information on shared channel. With this addition, user can know the owner of the shared channel.
This pull request just adds a deprecation notice to the `StartRTM` functions that call `rtm.start` in favor of `ConnectRTM` and `rtm.connect` based on this announcement: https://api.slack.com/changelog/2021-10-rtm-start-to-stop No functional impact, just comments.
Slack has a feature called 'Send emails to Slack' - https://slack.com/intl/en-gb/help/articles/206819278-Send-emails-to-Slack When emails are sent to this channel, they become Slack files with additional fields containing sender and receiver information. I added two new fields to properly support the unmarshaling of file metadata.
Signed-off-by: sivchari <[email protected]>
Signed-off-by: sivchari <[email protected]>
close #1363 ##### 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) - [x] exposes a previously private type, const, method, etc. - [x] is it application specific (caching, retry logic, rate limiting, etc) - [x] 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.
At incident.io, we often iterate over the contents of Slack views, and often want to add the block ID to various bits of observability (logs, traces). Doing this is quite difficult, because the `Block` interface doesn't allow easy access to the ID — we have to cast each possible kind of block to pull this out. This PR introduces an `ID()` function to the `Block` interface, making this kind of thing much easier. I added some tests along the way, and also noticed that `CallBlock` doesn't allow the ID to be set. This doesn't affect us, but you might wish to fix that.
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.
Pull Request Guidelines
These are recommendations for pull requests.
They are strictly guidelines to help manage expectations.
PR preparation
Run
make pr-prepfrom the root of the repository to run formatting, linting and tests.Should this be an issue instead
API changes
Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes.
Examples of API changes that do not meet guidelines: