村濱一樹
- 合計アクティビティ 403
- 前回のアクティビティ
- メンバー登録日
- フォロー中 0ユーザー
- フォロワー 4ユーザー
- 投票 28
- 受信登録 137
アクティビティの概要
村濱一樹さんの最近のアクティビティ-
村濱一樹さんがコメントを作成しました:
https://developer.cybozu.io/hc/ja/articles/204791550-%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AE%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%81%AE%E6%9B%B4%E6%96%B0#anchor_changeRecordStatus ...
-
村濱一樹さんがコメントを作成しました:
なるほど、作成者Aがトリガーとなって追加したいときがあるのですね。そうすると若干プロセス管理では叶えれなさそうなケースな気がしてきました。。 もしも確認者B/最終者Cに、レコードに気づかせ、確認させるためにプロセス管理を用いてるのであれば、逆にプロセス管理をやめて、 kintoneカスタマイズなどでやるのも手かなと思いました。 1. 上長確認用のチェックボックスフィールドを用意（このと...
-
村濱一樹さんがコメントを作成しました:
できましたか、レス遅れましてすいません、良かったです！
-
村濱一樹さんがコメントを作成しました:
下記のように差し戻しを用意するのはどうでしょうか？ https://pj.asunote.jp/workflow/wf-002/ > 作成者A（送付）→確認者B（確認）→最終Ｃ（受領） 個人的にはこの流れならば、 - 確認者Bや最終Cで修正したい場合は「差し戻し」アクションをして作成者Aにもどす - 最終Cで完了したあとに気づいた場合は、特例として最終Cがレコードを編集するか、新しく...
-
村濱一樹さんがコメントを作成しました:
ご認識の通り、初期状態では、ルックアップで取得した状態にはなりません。 明示的にlookupの取得を動作させる方法があるので下記確認ください。 https://developer.cybozu.io/hc/ja/articles/201941984-%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89%E8%BF%BD%E5%8A%A0%E3%82%A4%E3%83%...
-
村濱一樹さんがコメントを作成しました:
https://developer.cybozu.io/hc/ja/articles/201941964/comments/203496703 あとはこの案もありますね。 懸念としては削除失敗や削除完了する前に遷移する可能性はありますが、 厳密に待つ必要がなければこっちのほうが実装楽かとはおもいます。
-
村濱一樹さんがコメントを作成しました:
標準機能ではできないですね。。 JSカスタマイズ前提でよければ、思いついたのが 1. 既存の削除ボタンを非表示にする2. 独自の削除ボタンを作成3. 独自の削除ボタンでは、APIを利用してレコードを削除し、成功後画面遷移を任意の場所にさせる ということであればできそうです。 他にもいい案あるかもしれませんが
-
村濱一樹さんがコメントを作成しました:
はい、関数（ここでいうとイベントのハンドラ）はreturnすると抜けますね。 なので、Orderがあると関数はおわります、ということなのでEdit画面表示イベントしか実行されてなさそうにいえます。 ためしにifでreturnしないでみるとどうでしょうか。 （ここまで書いて気づいたんですが下記と要素の取得が違うのもきになりました
-
村濱一樹さんがコメントを作成しました:
最初のほうで、 #order があるとreturnしてるので、 1. edit画面入る2. 要素が作成される(#order)3. 値を変更しても、すでに#orderができてるので上記のコードは最後までreturnされない という流れがありそうだなとおもいました。
-
村濱一樹さんがコメントを作成しました:
https://developer.cybozu.io/hc/ja/community/posts/360027721512-create-change%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E6%99%82-%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB%E3%83%89%E3%81%AE%E5%80%A4%E3%81%AE%E6...