LINE WORKS Developers : コミュニティプロフィール

Content

中村恭輔

投稿2
コメント5
いいね受信0
いいね送信0

BEST選択数 0

原文を表示

クイック返信の実装方法

ご連絡ありがとうございました。正常にQuickReplyが表示されることを確認しました。ご対応ありがとうございました。

Bot 2021.05.29

いいね0
原文を表示

クイック返信の実装方法

ご回答ありがとうございます。不備である旨、承知しました。ご修正の程よろしくお願いします。＞開発に報告の上、修正を予定しております。＞修正が完了いたしましたら、こちらの投稿にてご連絡させていただきますので、今しばらくお待ちください。ちなみに、上記はクライアントサイド（モバイルアプリ）、サーバーサイドどちらの修正になりますでしょうか。（つまり、修正後にあるべき状態にするためには、モバイルアプリのバージョンアップが必要となりますでしょうか。）メンバー全員のモバイルアプリを指定バージョンに上げるためには、少々時間を要します。また、FlexTemplate とQuickReplyのうち、どちらかというとQuickReply機能を優先的に使用したい機能を開発しています。そのため、上記のご質問のご回答によって、以下のように今後の進め方が変わってくることになります。ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー【①本不備がサーバーサイドのみの場合】修正後必ずメンバー全員に状態が反映されるため、FlexTemplate 使用前提での開発を継続⇒不備解消後に一部コード修正、としたい　と考えております。（暫定的に修正まではボタンテンプレートにて返信用ボタンをFlexTemplateに続いて出力、かつ直前以外のトーク中のボタンをクリックしないように運用でカバー、不備修正後、ボタンテンプレート送信のコメントアウト作業を予定。）【②モバイルアプリのバージョンアップも必要な場合】不備解消後にQuickReply対応をしたとしても、全員のモバイルアプリがバージョンアップされるまで、QuickReplyボタンが表示されない人（手動で文字を入力しないと返信できない人）が残ってしまうことになります。また、モバイルアプリのバージョンを参照して、対応後バージョンの場合のみQuickReply、対応前であればボタンテンプレート、、、といった分岐処理もできないものとみています。そのため現実的にFlexTemplate とQuickReplyは共存できないものとして捉え、そもそもQuickReplyを優先的に使用したい本機能では、FlexTemplateを使用しないよう、開発の方針を転換したいと考えています。ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー完了したタイミングのご連絡に先立ち、対応方針や対応時期感がわかった段階で、こちらの投稿にご連絡をお願いできますでしょうか。以上、よろしくお願いします。

Bot 2021.05.18

いいね0
原文を表示

クイック返信の実装方法

↑quickReplyが表示されない実際のJSONオブジェクトです（一部加工）。quickReplyの位置はここではないのでしょうか。なお、「"type": "flex"」でなく「 "type": "text"」とする、通常のメッセ―ジでは、この位置でquickReplyの表示がされることを確認済です。

Bot 2021.05.15

いいね0
原文を表示

クイック返信の実装方法

{ "accountId": "XXXXXX@YYY", "content": { "type": "flex", "altText": "(登録内容)", "contents": { "type": "carousel", "contents": [ { "type": "bubble", "size": "nano", "header": { "separator": false, "layout": "vertical", "type": "box", "contents": [ { "type": "text", "text": "2021/05/09", }, { "type": "text", "text": "07:29:39", } ] }, "body": { "type": "box", "layout": "vertical", "contents": [ { "type": "text", "text": "AAAA", }, { "type": "text", "text": "ああああ",} ] } }, { "type": "bubble", "size": "nano", "header": { "separator": false, "layout": "vertical", "type": "box", "contents": [ { "type": "text", "text": "2021/05/02", }, { "type": "text", "text": "07:21:24", } ] }, "body": { "type": "box", "layout": "vertical", "contents": [ {"type": "text", "text": "BBBB", }, {"type": "text", "text": "いいいい",} ] } } ] }, "quickReply": { "items": [ {"action": { "type": "message", "label": "もっと見る", "text": "もっと見る" }} ] } } }

Bot 2021.05.15

いいね0
原文を表示

1:1トークルームの判別について（受信messageのsourceプロパティに含まれる、accountId、roomIdの出現仕様について）

ご回答ありがとうございました。シナリオは想定いただいているとおりです。（より厳密にいえば、①のルームIDは特定のルームなので、管理者画面のトークの監査から確認します。）ノード出現について、連絡ありがとうございました。疑問点クリアになりました。なお、ドキュメント（ https://developers.worksmobile.com/jp/document/100500901?lang=ja）では、いかなる場合もアカウントID、ルームID双方必須で出現する様に読み取れますので、改訂をご検討ください。ありがとうございました。

Bot 2021.05.06

いいね0