/*
* Hanzo Cloud API
*
* 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/.
*
* The version of the OpenAPI document: v1
*
* Generated by: https://openapi-generator.tech
*/
use crate::models;
use serde::{Deserialize, Serialize};
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Capabilities {
/// 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.
#[serde(rename = "actions", skip_serializing_if = "Option::is_none")]
pub actions: Option<bool>,
/// 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.
#[serde(rename = "dm", skip_serializing_if = "Option::is_none")]
pub dm: Option<bool>,
/// 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.
#[serde(rename = "group", skip_serializing_if = "Option::is_none")]
pub group: Option<bool>,
/// 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.
#[serde(rename = "media", skip_serializing_if = "Option::is_none")]
pub media: Option<bool>,
/// 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.
#[serde(rename = "thread", skip_serializing_if = "Option::is_none")]
pub thread: Option<bool>,
}
impl Capabilities {
pub fn new() -> Capabilities {
Capabilities {
actions: None,
dm: None,
group: None,
media: None,
thread: None,
}
}
}