26098cc400
## 概要 [Task1831: API実装（タスク一覧取得 | admin）](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/1831) - AdminがAPIを呼び出したときの処理である、アカウント内のTask情報すべてを取得するロジックを実装 ## レビュー対象外 - Transcription開始日時と終了日時が必須プロパティになっている - [Task一覧APIのResponseで省略可能でないといけないプロパティが必須になっている箇所を修正する](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/OMDSDictation/_workitems/edit/1956)で修正予定のため - ユニットテストが未実装 - [テスト実装（タスク一覧取得 | admin）](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/OMDSDictation/_workitems/edit/1955)で実施予定のため - API I/Fのstatusのバリデーションがされていない - [Task一覧APIのstatusの入力チェックを行うデコレータを実装する](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/OMDSDictation/_workitems/edit/1957)で実施予定のため ## レビューポイント 1. SQLの発行方法は問題なさそうか - ~.entityに依存関係を記述( `@OneToOne(...)` や `@OneToMany(...)` )し、TypeORMでの取得時の挙動に任せる方法でよさそうか 2. Permissionテーブル以下も含めて一括でTypeORMによるクエリビルダーに任せたかったが、他の上手くいっている構造と同じ指定をしてもSQL発行時に指定したカラム名を取ってこなくなるという問題が解決できなかったため、2回に分けて取ってくるようにしたが許容可能そうか？ 3. 各テーブルでRepositoryを作ってEntityを定義し、他RepositoryからはそのRepository配下のディレクトリを参照するという形を取ってみたが、方針として問題ないか - 各テーブルを個別に取得したい場合があるかも？という予想があったため 4. Serviceのつくりとして問題はなさそうか（roleによる呼び分けの実装方法など） 5. RepositoryDTO→ControllerDTOの型変換が複雑であったため、専用のconvert.tsというファイルに分離したが、方針として問題なさそうか ## 動作確認状況 - ローカルで確認