TODO管理機能の実装 #17
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
現在の状態（なぜOpenか）
繁忙期に作業が積み重なり、優先順位が管理できていない。
次にすること（Next Action）
仕様確定後、データモデル設計とバックエンド実装から開始する。
ブロック要因
なし
概要
RedmineチケットライクなTODO管理機能を実装する。圃場・作物・品種を作業対象に紐づけ、既存の施肥計画・田植え計画と連携する。
背景・目的
繁忙期に作業が積み重なると「どれから手を付けるか分からない」問題が発生する。優先順位をドラッグ&ドロップで管理できるTODOシステムで解決する。
完了条件
関連
施肥計画（FertilizationPlan）、田植え計画、将来：農薬散布記録
機能要件詳細
TODOアイテムのフィールド
作業対象（M:N、すべて任意）
計画との連携（M:N）
UI要件
一覧画面
詳細画面
技術要件
apps/todos/frontend/src/app/todos//api/todos//api/todos/reorder/で一括更新未確定事項（仕様確定が必要）
スコープ外
仕様化前の確認事項への回答を記録します。
質問と回答
圃場グループは独立モデルにするか
回答: 独立modelである必要はないと思います。
作業対象と計画リンクを分けるか
回答: 基本的に圃場が対象になる計画には、圃場が含まれていますのでそのケース自体存在しないと思います。計画の中の一部の圃場だけがTODOの対象になる事はあります。
実績系の無い作業種別をどう扱うか
回答: 田植え実績の受け皿はこれから作ります。実績系の無いものはこうやって作っていく事になると思います。ただし、計画に紐づかないTODOがあるのと同じく、実績系のアプリに紐づかないTODOもあり得ます。
施肥TODO完了時の実績生成をどう考えるか
回答: 施肥TODOという概念を組み込むのであれば、施肥計画->施肥実績にするフローを、施肥計画->施肥TODO->施肥実績にするフローになりえるという方向で考えるのが良いと思います。他の件も同じです。作付け計画以外のすべての計画も、間にTODOを入れられるようにしたいです。
田植えTODO完了時の扱い
回答: 田植え TODO の完了時は、田植え実績（あとで実装します）です。
作業種別 enum の方針
回答: すべての計画と、計画に紐づいていない、実績がenumの対象になるようにしたいです。それとそのどれにも当てはまらない、「一般」。
並び順の仕様
回答: 並び順は優先度を内部に持たせて、基本はFILOですが、ドラッグ操作で順番入れ替えられるようにしたいです。無理なら矢印ボタンで移動出来るように。
計画からTODO生成の導線は MVP で必要か
回答: 「計画から TODO を生成する」導線は MVP で必要です。
ここまでで確定した理解メモ
指摘事項
A. モデル定義の不整合
[7.1 Todo]
yearフィールドが欠落yearを持つ」と書いているのに、7.1のテーブルに列がない。決定事項であればモデル表に追加すべき。[7.3 TodoCrop / TodoVariety] フィールド定義がない
todo FK,crop FK,unique_togetherなど最低限の定義が必要。B. ロジックの曖昧さ
[7.1.2 並び順] FILO + priority の実装が未定義
[11. バリデーション]
field_ids が計画外圃場を含む場合はエラーの条件が曖昧C. 設計の一貫性
[7.4 TodoPlanLink] 畔塗リンクが「要検討」のままで work_type に含まれている
work_typeの初期案にはlevee_workがあるが、TodoPlanLink の対応先が要検討。[8.3 作成 API]
plan_idから具体的な FK への変換仕様がない{"plan_type": "fertilization", "plan_id": 8}だが、モデル側は FK が種別ごとに分かれている。Serializer でどう吸収するか方針を追記すべき。D. 実装計画の漏れ
[12.1 Backend]
admin.pyと migration が省略admin.py登録とmakemigrations/migrateが必須ステップ。実装順(12.3)にも含めると実装者がそのまま使える。E. ドキュメント体裁
見出し階層の揺れ
## 7.配下のサブセクションが## 7.1（##）になっているが、親が##なら子は###が正しい。9〜12章も同様。確認を推奨する事項
# | 事項 | 理由 -- | -- | -- 1 | done → todo への差し戻しを許可するか | completed_at のクリア/保持ポリシーが不明 2 | TodoTargetField.field の PROTECT は適切か | Field 削除時に TODO が削除できなくなる。想定ユーザーの運用上これでよいか確認 3 | reflect_to_record の命名 | フラグの意味が「完了時に実績連携する」なのに名前がやや遠回り。links_to_record 等を検討全体的には実装に進める品質ですが、B（ロジックの曖昧さ） の2点は実装時にブレやすいので先に決定しておくことを推奨します。
</html>仕様書案（
改善案/TODO管理機能仕様書案.md）でかなり整理できたため、現時点で実装前に詰めるべき残論点だけを記載します。現時点の残論点
work_typeenum の初回実装範囲pesticideやother_recordedを先に入れるか、現行アプリに対応するものだけに絞るかを決めたい。A. status=done のみ/B. 実績入力画面への導線返却/C. 仮レコード生成のどこまでやるか未確定。doneかつ連携済み TODO を物理削除禁止にするか、論理削除を入れるか、参照整合性付き物理削除にするか未確定。work_typeとplan_typeの将来追加ルール実装前に追加で決めたい点
PATCH /api/todos/{id}/でもstatus=doneにできるのか、完了はPOST /api/todos/{id}/complete/専用にするのかを決めたい。done -> todo/doingを許可する方針は仕様書案にあるが、その時に既に作られた実績リンクをどう扱うかは未定。TodoCompletionLinkを残すのか、警告だけ出すのか、差し戻し不可条件を設けるのかを決めたい。year) と計画年度の整合性チェックレベルtodo/doingのみ再採番するのか、閉じた TODO を含む全件順序なのかを明示したい。SpreadingSession作成導線へつなぐ方針は整理済みだが、TODO からどの粒度のデータを初期注入するかは未確定。このあたりが固まれば、MVP 実装に入るための意思決定はほぼ揃う認識です。
引き継ぎしやすいように、未確定論点の潰し順と、最初に決めたい内容を整理しておきます。
論点の潰し順（依存関係が強い順）
work_typeの初回実装範囲year) と計画年度の整合性チェックwork_typeとplan_typeの将来追加ルールこの順を推す理由:
最初に決めたいこと:
work_typeの初回実装範囲ここが決まると、以下が連動して決めやすくなる。
Todo.work_typechoices候補案
案A: 現行アプリ対応だけに絞る
generalfertilizationrice_transplantdeliverylevee_workメリット:
デメリット:
pesticideなどを追加すると choices 変更が必要案B: 将来見込みも先に入れる
generalfertilizationrice_transplantdeliverylevee_workpesticideother_recordedメリット:
デメリット:
現時点の推奨
MVP は 案A（現行アプリ対応だけに絞る） を推奨。
理由:
計画 -> TODO -> 実績の導線を既存機能に対して成立させることが重要pesticideを追加する余地は残せる次アクション
次に判断するなら、以下を決める。
work_typeは案Aで固定するかこの 2 点が固まると、MVP 実装の前提がかなり明確になる。