一覧画面にて、JSからREST APIを使ってレコード更新後、リロードをせずに即時一覧に反映させたいです。

具体的には、レコードごとに「検収日を今日に変更」みたいなボタンを設置し、押すとREST APIで更新して画面に反映させたい考えです。

リロードするラグが嫌なので、kintone側でajaxで同じページのrecord/list.jsonを再読込してDOM反映させてほしいのです。

このような方法はありますでしょうか？

ちなみに、これをやる前に試したのは'app.record.index.edit.show'のタイミングでもう中身をそのように変更してreturn eventして書き換えられたものが入力フォームに反映されるだろうと踏んでやってみたのですが、フォームにも反映されず値にも反映されず。app.record.index.edit.showで有効なのはdisabledくらいなのですかね、残念です。

Masayuki Ishikawa 様

お世話になっております。developer network事務局です。

一覧画面でリロードなしで値を変更することはできません。

ご期待に沿えず申し訳ございません。

お世話になっております。

一覧画面の各レコードに表示する内容を変更したいです。

具体的には、アプリAの「予算単位」という項目に、現状「予算単位」しか表示されていないですが、

   アプリA「予算単位」 + アプリB「予算単位名称」

という表示に変更したいです。

このように一覧の描画処理のようなことは可能でしょうか？

Yuta様

お世話になっております。cybozu developer network 運営でございます。

別アプリのレコードの一括取得をした上で、カスタマイズビューを用いて表示することで可能かと思います。

恐れ入りますが、こちらのコメント欄は記事内容のフィードバック目的となっているため、
記事から派生した技術的なご質問はcybozu developer コミュニティをご活用ください。

よろしくお願い致します。

「レコード一覧のメニューの右側の空白部分の要素を取得する」の説明に
「利用できる画面
レコード一覧画面」
があった方がいいと思います。

Mogami Takafumi 様

お世話になっております。cybozu developer network 運営でございます。

フィードバックくださり、ありがとうございます。

ご指摘いただいた内容について検討させていただきます。

今後とも、cybozu developer network をよろしくお願いいたします。

この記事では「複数の条件の括弧がandやorでつなげられたクエリの場合、各括弧内の条件は最大で14個です。15個以上を指定したクエリの場合はエラーが発生します。」と、記載されていますが、例示された条件より　沢山の条件を指定しても、エラーにはなりませんでした。

実際、フィルタリング条件をQueryに指定数るとlist.jsonなるURLに遷移するようですが、そのHTTP statusコードは200　ｏｋで、エラーメッセージは出力されませんでした。

それは、「15個以上を指定したクエリの場合はエラーが発生します」という記述が誤記だということを示します。

多分、この記事の作成日2014/05/08当時より　沢山の条件を指定可能になったのであろうとは　推定できますが、フィルタリング条件を動的かつ簡単に検索できるようなプラグインの開発を使用とした場合、検索条件の個数の上限を決めることができかねます。

つきましては、現時点で　正しい、Queryの上限値を掲載してください。

追伸。

境界条件を探ろうとして、orで連結した条件が38個のqueryconditionが2706文字未満の場合は、絞込結果が表示されて、
条件の個数は変えないで、like条件に含まれるキーワードの文字数を増やしたら、下記のメッセージのみが含まれる白い画面に成りました。

「
Bad Message 431
reason: Request Header Fields Too Large
」

小瀬 様

お世話になっております。cybozu developer network 事務局です。

1. 「複数の条件の括弧がandやorでつなげられたクエリの場合、各括弧内の条件は最大で14個です。」という記載について

and や or で複数の条件の括弧をつないだ場合、それぞれの括弧の中で14個までつなげられます。

添付いただいた画像内のクエリ（f5760951 in (“5760955”) … の部分）ですと、上記の条件に適用されないかとお見受けします。
そのため、エラーは出力されない状況であるかと存じます。

2. 「Bad Message 431 reason: Request Header Fields Too Large」について

こちらのエラーについてですが、リクエストヘッダー自体が大きくなりすぎているため、絞り込みを実行する前でエラーが起きている状態です。

また、クエリについて明確に文字数やフィールド数に制限があるわけではありません。
ただし、クエリが長すぎるとエラーにはなってしまうため、気をつけて使っていただくようお願いしております。
加えて、過度に複雑なクエリだとリクエスト自体も重くなってしまいますので、ご注意ください。

応答ありがとうございます。

>また、クエリについて明確に文字数やフィールド数に制限があるわけではありません。
>ただし、クエリが長すぎるとエラーにはなってしまうため、気をつけて使っていただくようお願いしております。
>加えて、過度に複雑なクエリだとリクエスト自体も重くなってしまいますので、ご注意ください。

　ご指定の条件にそうクエリを発行するようなプラグインを実装したいと思います。

---

しかしながら、今般の回答で示唆されている「ご指定の条件にそうクエリ」について、ドキュメント記載内容が不足しているように観えます。

これまでの処、「”クエリが長すぎる”と見なされるのは、何文字が境界か？」「”過度に複雑なクエリ”とみなされる条件は何か？」が解らないため、

「フィルターの条件の演算子の種類は固定し、演算子に適用する値のみを動的に変更可能にする」という風なプラグインを作った時、

添付の図に示すような「曖昧な条件で、kintoneが誤動作する可能性がある」と表示しつつ、

「誤動作しないカモしれないので、過度に複雑とみなされるカモしれないクエリの発行如何を利用者の判断に委ね、

結果として『kintoneに過度に複雑とみなされるクエリを発行する場合もある』という風にしかプラグインを実装できないでいます。

つきましては、「kintoneが誤動作またはエラーメッセージを出さないためのクエリとは、どのような境界条件のクエリなのか？」を、ドキュメントに明記していただけませんでしょうか？

また、「リクエストヘッダー自体が大きくなりすぎている」ということをクエリ発行前に検知する為には、リファラやクッキー他 kintoneの画面遷移におけるhttp headerに含まれうるパラメタの総文字数等、クラグインの中のJavaScriptコードで計算することが困難な情報（Kintoneの絞り込みフィルタ機能の利用に限定しなければ予測計算不能な境界条件）もあろうかとは思いますが、kintoneの利用上　許容できる精度で「リクエストヘッダー自体が大きくなりすぎる」ということを予測計算できそうな”近似式”も　教示いたただければ幸いです。

小瀬 様

お世話になっております。cybozu developer network 事務局です。

クエリに利用可能な文字制限について、開発元に確認いたしましたが、仕様化されておらず、そこまでの保証ができない値のため、開示は差し控えさせていただきます。

ご要望にそえず、申し訳ございません。

cybozu developer network 事務局  担当殿；

なにはともあれ、このページの元記事の"レコード一覧のクエリ文字列を取得する"の記載について、「開発元に確認」が必要となるような　記載内容の不足までは認識していただけたようで、ありがとうございます。

しかしながら、

>ただし、クエリが長すぎるとエラーにはなってしまうため、気をつけて使っていただくようお願いしております。

という指示をいただいておりましたが、”長すぎる”と見なす値を　問いあわせると、

＞クエリに利用可能な文字制限について、開発元に確認いたしましたが、仕様化されておらず、そこまでの保証ができない値のため、開示は差し控えさせていただきます。

という回答だったのも矛盾で、「実施不能な指示をしていた」ということですね？

それは、Kintoneの　どのような方針に起因した”結論”でしょうか？

例えば；

（A)　Kintoneのドキュメント体系の不整備；

　表計算ソフトとして有名なMS-EXCELの場合、主として入門者向けのHELPドキュメントか関連書籍とは別に、EXCELの機能拡張用マクロ等の開発者向けに数百ページを上回る　精細なSDKドキュメントが完備されています。

　一つのドキュメントに「入門者向け情報」と「プラグイン開発者向けの精細な情報」とを　混在させるようなドキュメント体系は、結局”入門者”にもプラグイン開発者にも　解りにくいドキュメントになるので、分離し、各々の　想定読者に特化したドキュメントを準備するのが　高品質なドキュメント体系だと思います。

かたや、kintoneでは「入門者向けのドキュメントには書かないような精細なドキュメントを、Kintoneは準備しようとしていない」ということでしょうか？

(B) サポートサービスの不整備または　有償の付加サービスの未購入；

　表計算ソフトとして有名なMS-EXCELの場合、無償でナレッジを提供していてエンドユーザによるセルフ検索が出来るサイトの他に、

「既知のナレッジから、関連性の高そうな情報を　当該製品の使い方について見識の高いサポータがピックアップしてくれる」という有償サービスや、

「既知のナレッジに無い、未知のインシデントについて、ソリューション（解決）を創出するよう努力する」という有償・付加サービスや、

「既知のナレッジに無い、未知のインシデントについて、ソリューション（解決）を創出するよう努力することについて、開発元のマネージャ等の関連者も含めた従事時間や優先度やを高める」という有償・付加サービス等、

何段階かの費用に応じたSLA（サービス・レベル・アグリーメント）が整備されています。

Kintoneの場合、「既知のナレッジに無い、未知のインシデントについて、ソリューションを創出するよう努力する」ようなサービスは提供しようとしていない、ということでしょうか？

-----------------------

"Kintoneの仕様　Kintone標準の絞り込み機能と同等の自由度で　より簡単に絞り込み条件を変更できるようなプラグインを作成した時、

「もうすこし短い条件にしないと、kintoneが誤動作する可能性が在ります」というエラーメッセージやオペレータ介入要求は、

かなり不格好な仕様ですが、そうせざるを得ない原因がKintoneの開発元にあることに　甘んじなければならないのでしょうか？

小瀬様

ご質問をありがとうございます。

>（A)　Kintoneのドキュメント体系の不整備
の内容については、当ドキュメントへのフィードバックと認識いたしました。検討させていただきます。

当コメント欄はAPIドキュメントに関するフィードバック受付のため、先の回答以上の内容は対応いたしかねます。何卒ご容赦ください。

なお、開発への改善要望については、製品ヘッダー「？」をクリックした後の「kintoneの改善に協力する」にて、直接届けることが可能になってございます。

APIの仕様に関するサポートは、メールにておこなっております。

https://jp.cybozu.help/k/ja/trouble_shooting/developer/developer_qa.html

今回のお問い合わせのような、API の仕様についてお知りになりたい場合は、メールの個別やりとりにて対応することが可能です。ご案内が遅くなり、大変失礼いたしました。

このたびは貴重なご意見をいただき、ありがとうございました。