非アクティブな Dojo を非表示にする仕組みが欲しい (例: CoderDojo 小手指)

[yasulab]

CoderDojo 小手指の例

CoderDojo 小手指の代表者が入院中で、現在は非アクティブな状態になっている 🏥 😷

あーそうですねぇ。
恐らく年内は再開が厳しそうなので…

「なるべく早く、再開したいと思います！」とのことなので、Dojo の表示/非表示を簡単に切り替える仕組みがあると便利そう? 🤔💭

cf. CoderDojo の運営が難しくなったときのガイドライン
https://coderdojo.jp/docs/how-to-suspend-your-dojo

[yasulab]

うーん、DBで削除しようと思ったんですが、そうすると dojo_id で紐づいている他のカラムにも影響が出そうで微妙ですね >< 💦

[yasulab]

再開の見込みのある休止の場合、status カラムを追加してそこで表示/非表示を切り替えるのがいいのかなぁ🤔💭 cc/ @nalabjp

.oO(統計情報にうまく反映させるようとすると結構な工数がかかりそう 💦だとしたら後回しにしちゃうかなぁ)

[nalabjp]

論理削除やstate的なのは個人的には選びたくない設計なんですが、
手っ取り早いのは手っ取り早いですね。
あとはscopeで特定idを弾くとかも出来るかと思いますが、
defalut_scopeは使いたくないので非表示にしたいトコロ全てでそのscopeを呼ぶってことをやらないといけないですねぇ。（そんなに沢山あるわけでもなさそうなので大した工数ではないかも）

[yasulab]

コメントありがとうございます! Dojo モデルが has_many ... dependent になっているので、そうするとシンプルに DB から Dojo.find(77).destroy # 77: 小手指 を実行しちゃうのが早いですかね? 🤔💭

has_many :dojo_event_services, dependent: :destroy
has_many :event_histories, dependent: :destroy

[yasulab]

(正確には実行するだけじゃなくて、dojos.yml と dojo_event_service.yml から id: 77 の部分の削除かな ✂️ )

[nalabjp]

event_historiesは実績としては残したいですよねぇ。
あとは、再開された際にそのまま引き継げると楽といえば楽なので、
個人的には非表示対応の方が良いかなぁと思っていますがどうでしょうか？

[yasulab]

あとは、再開された際にそのまま引き継げると楽といえば楽なので、
個人的には非表示対応の方が良いかなぁと思っていますがどうでしょうか？

はい、今後のことを考えると非表示対応の方が良いかなと考えています。例えば CoderDojo Zen API とのスムーズなデータ連携ができるようになったら、 Zen 上で非アクティブに変更したら coderdojo.jp からも非表示になる みたいな実装にも繋がって色々と便利にしていける可能性が広がりそうです 💭

ただ今回の小手指の件に関していえば、もともと Google Form で運営されていた関係で統計情報にも大きな影響がないので、「DB上からは削除 && yaml はコメントアウト」という対応でも良いかなと考えています🤔

対応後もこちらの Issue は閉じないで残しておき (例えばアナグラさんのように新しく join する人用のタスクとしてストックしておき) 、別途どこかのタイミングで対応する形でも良いのかなぁとふんわり考えています 😌

[nalabjp]

もともと Google Form で運営されていた関係で統計情報にも大きな影響がないので、「DB上からは削除 && yaml はコメントアウト」という対応でも良いかなと考えています

なるほどなるほど😌

[yasulab]

こちらの件、弊社のリソースの関係で「ワークアラウンドな対応として物理削除をやる?」といった話も挙がっていますが、 @naopontan さんにお願いできそうなので、ナラさんの次のアイデアの実現可能性について模索する方向で動いています 🔧 💨 cf. #314

event_historiesは実績としては残したいですよねぇ。
あとは、再開された際にそのまま引き継げると楽といえば楽なので、
個人的には非表示対応の方が良いかなぁと思っていますがどうでしょうか？