我正在试图找出向用户发布短暂消息然后将其删除并用所有人都可以看到的消息替换它的机制.与giphy类似的行为,其中Slash Command显示交互式短暂消息,并在用户决定发送哪个gif后创建频道消息.我也很想更新短暂的消息.我假设如果我们使用交互式短暂消息,可以通过response_url来完成.
我最初认为我只是创建一个短暂的消息chat.postEphemeral,然后调用chat.delete它,但它似乎chat.delete并且chat.update无法在使用创建的消息上调用chat.postEphemeral.
Slack消息指南似乎建议应该总是以短暂的方式处理多步骤交互流程,以便其他渠道用户在结果之前看不到所有中间消息,但我运气不好找出如何摆脱完成后的短暂.可能只是阅读不好,但任何帮助表示赞赏.
编辑更多详细信息:
有关使用response_url和postEphemeral状态的文档
当您使用chat.update或replace_original选项替换消息时,您无法将消息的类型从ephemeral更改为in_channel.一旦发出消息,它将终身保持其可见性质量.
消息指南建议:
如果用户已启动具有多个步骤的操作,则这些步骤应显示为仅对该用户可见的短暂消息,直到整个操作完成,以避免每个人都混淆该频道.
据推测,我应该能够创建一个交互,我首先发送in_channel交互式消息.
response_url和传递给他们一系列短暂的消息response_type: 'ephemeral'和replace_original: false?response_url的编辑,对吧?Tay*_*ary 11
一些短暂的消息可以被"软"删除/替换,但仅在作为具有按钮或菜单等交互功能的消息的一部分发布时.单击按钮或进行菜单选择时,您有机会指示Slack"删除"原始消息,或将其替换为新消息.这些文档详细说明了使用响应并response_url实现了这一点.
用chat.postEphemeral它自己创建的消息没有交互式功能,永远不能被明确删除.一旦它被交付,它就像一个幽灵,并会在重启或刷新后消失.
按顺序回答您的项目符号问题:
response_url在最终用户按下按钮,选择菜单项等之前,新的短暂消息将无法使用.response_url将最终到期("使用response_url,您的应用程序可以在动作调用的30分钟内继续与用户进行最多5次交互.")如果原始消息是非短暂的,则使用chat.update对于更长的时间线来说是更好的策略.随着短暂的消息,它更像是"尽你所能"的策略.刷新后,它们最终会被清理干净.chat.postMessage直接从斜杠命令或交互中使用而不是链式效果,更容易启动新的"in_channel"消息.我搜寻了如何做到这一点的高低,最后找到了答案。
您对操作的回应必须使用以下内容
{
'response_type': 'ephemeral',
'text': '',
'replace_original': true,
'delete_original': true
}
Run Code Online (Sandbox Code Playgroud)'delete_original': true是这里的关键,据我所知,任何API指南都没有提及,但是在API领域指南中,Top-level message fields
如果您希望更改response_type消息的标题而不是删除消息,则必须先删除短暂消息,然后使用来发布相同的消息'response_type': 'in_channel'。
在我的用例中,我想获取一个临时消息,然后使用与渠道内消息完全相同的消息正文重新发布。我还没有找到一种方法来检索您的临时消息的内容,因此,我找到的最佳方法是传递按钮中生成的临时消息的所有必要数据,value以便您的操作处理程序可以读取此数据并动态地重新创建消息身体。
在我的情况下,这是用于执行查询的用户输入。在最初的临时消息发布到通道内版本发布之间,数据库中的数据可能会有所不同,这是不可能的。您可能可以直接通过此的字符数限制value字段发送JSON字符串,并且避免进行额外的数据库调用,并避免将消息发布到频道时发生消息更改的风险。value为2000,因此JSON传递受到极大限制。
假设在最初创建临时消息时以及在通道内重新创建时使用相同的代码来生成此主体,则您应该收到相同的主体,并且基本上能够将临时消息更改为通道内消息。
| 归档时间: |
|
| 查看次数: |
3380 次 |
| 最近记录: |