You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Endpoint to get Channel ID by slack channel name #1158
There should be a way to get a slack channel ID using slack channel name. This is important for a scenario where user tries to create a slack channel, but get's error because slack channel already exists with the name!
Other option:
Include channel ID in error response 'name_taken' error
Category (place an x in each of the [ ])
slack_sdk.web.WebClient (sync/async) (Web API client)
Hi @adiberk! This is outside of the realm of the SDK, but we're happy to pass on this feedback to the appropriate team.
Can you provide a little bit more context for the specific use case you've referenced above? If a user tried to create a channel, and the channel already existed, what would be done with the returned channel ID?
To answer question: You would then use that channel ID to get the channel and then continue doing what you were trying to do via the API.
Scenario:
Let's say for whatever reason you want to post a message to a slack channel. You have the name of the channel, and you either create a slack channel if one does not exist or use the existing one.
Ideally you have the channel ID from when you create it. Therefore you know one exists already and you get it using that ID. However let's say you don't have that ID (data corruption etc. name any reason). There should definitely be a way to get that channel ID back given that you have the unique name. Or better yet, instead of passing in channel ID in conversation_info you pass in channel name and you get the Channel. (ie. you use a name to create a slack channel, you should be able to then get the slack channel by that name - especially since it is unique). I don't believe I am the first one to request something like this. I have seen this mentioned in another issue.
Got it. Thanks for the thorough rundown. This will make it easier for the receiving team to understand the context of the request. You're correct in that it's been raised before; a shallow search turned up #405, for example.
Unfortunately, as the response provided there indicates, this change remains beyond the scope of the SDK, but we'll continue to pass on the feedback that this is a highly desired adjustment and advocate for its implementation.
Activity
misscoded commentedon Jan 4, 2022
Hi @adiberk! This is outside of the realm of the SDK, but we're happy to pass on this feedback to the appropriate team.
Can you provide a little bit more context for the specific use case you've referenced above? If a user tried to create a channel, and the channel already existed, what would be done with the returned channel ID?
adiberk commentedon Jan 5, 2022
To answer question: You would then use that channel ID to get the channel and then continue doing what you were trying to do via the API.
Scenario:
Let's say for whatever reason you want to post a message to a slack channel. You have the name of the channel, and you either create a slack channel if one does not exist or use the existing one.
Ideally you have the channel ID from when you create it. Therefore you know one exists already and you get it using that ID. However let's say you don't have that ID (data corruption etc. name any reason). There should definitely be a way to get that channel ID back given that you have the unique name. Or better yet, instead of passing in channel ID in conversation_info you pass in channel name and you get the Channel. (ie. you use a name to create a slack channel, you should be able to then get the slack channel by that name - especially since it is unique). I don't believe I am the first one to request something like this. I have seen this mentioned in another issue.
misscoded commentedon Jan 6, 2022
Got it. Thanks for the thorough rundown. This will make it easier for the receiving team to understand the context of the request. You're correct in that it's been raised before; a shallow search turned up #405, for example.
Unfortunately, as the response provided there indicates, this change remains beyond the scope of the SDK, but we'll continue to pass on the feedback that this is a highly desired adjustment and advocate for its implementation.
Thanks for your understanding!