hanzo_client/models/capabilities.rs
1/*
2 * Hanzo Cloud API
3 *
4 * The Hanzo Cloud API as a customer calls it: every operation under /v1/ except the operator's admin product, relay routes, legacy spellings and capabilities still reached by flag. Tagged by product: the first path segment after /v1/.
5 *
6 * The version of the OpenAPI document: v1
7 *
8 * Generated by: https://openapi-generator.tech
9 */
10
11use crate::models;
12use serde::{Deserialize, Serialize};
13
14#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
15pub struct Capabilities {
16 /// Actions is whether the transport renders an INTERACTIVE control natively, and it is the flag to read before composing one. The vocabulary is a closed kind-tagged union (envelope.go), exactly four kinds, each carrying only its own field plus an optional label: command — a bot command to run (`command`), rendered as a button that invokes it. url — an external link (`url`), rendered as a link button. select — a menu (`options`, each a label and the value choosing it returns), rendered as a picker. approval — a reference to an approval request (`approval.id`), rendered as approve/deny controls bound to that id. False on every transport, and nothing refuses a send for it: actions are accepted, validated per kind, and flattened by renderText to one line each after the text — `[label] command`, `[label] url`, `[label] opt | opt`, `[label] approval requested: <id>`. So a caller that needs a real control must read this flag and degrade itself; a caller that only needs the choice communicated can send actions and take the text form.
17 #[serde(rename = "actions", skip_serializing_if = "Option::is_none")]
18 pub actions: Option<bool>,
19 /// DM is whether the transport carries a DIRECT message at all. True for slack, teams, telegram and whatsapp — whatsapp is nothing else, since the Cloud API addresses a person's number and there is no room a third party joins. False for discord, honestly: that ingress is guild-scoped slash commands — an interaction without a guild id is refused at the endpoint — so nothing ever arrives classified as a DM, no reply route is ever learned for one, and a send addressed at a Discord DM is refused 409.
20 #[serde(rename = "dm", skip_serializing_if = "Option::is_none")]
21 pub dm: Option<bool>,
22 /// Group is whether the transport carries multi-person rooms — a Discord guild channel, a Slack channel, a Teams channel or group chat, a Telegram group or supergroup. False on whatsapp alone, which has no such room to carry.
23 #[serde(rename = "group", skip_serializing_if = "Option::is_none")]
24 pub group: Option<bool>,
25 /// Media is whether the transport renders an ATTACHMENT natively. False everywhere, and a send is not refused for it: renderText flattens each attachment to one `kind: url (mime)` line after the text rather than dropping it. A transport whose egress hands its door the raw text would drop the attachment instead, and an attachment-only send would reach the platform with nothing to say — which is why the flag and the flattening are pinned together.
26 #[serde(rename = "media", skip_serializing_if = "Option::is_none")]
27 pub media: Option<bool>,
28 /// Thread is whether a reply can be threaded UNDER a specific message. True for slack alone: it is the only transport whose ingress reports a thread (thread_ts, published as the envelope's replyTo) and whose send posts back into it. Discord's replyTo makes an inline reply rather than a thread, Telegram's and WhatsApp's each quote one message, and Teams carries no reply target at all — a replyTo sent to it is ignored.
29 #[serde(rename = "thread", skip_serializing_if = "Option::is_none")]
30 pub thread: Option<bool>,
31}
32
33impl Capabilities {
34 pub fn new() -> Capabilities {
35 Capabilities {
36 actions: None,
37 dm: None,
38 group: None,
39 media: None,
40 thread: None,
41 }
42 }
43}
44