nik/OMDSCloud
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
64 Commits 1 Branch 50 Tags
Commit Graph

8 Commits

Author SHA1 Message Date
oura.a
e9af39bd47 Merged PR 71: API実装（ユーザー登録） 
## 概要
[Task1593: API実装（ユーザー登録）](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/1593)

https://dev.azure.com/ODMSCloud/ODMS%20Cloud/_git/ODMS%20Cloud
users.controllerにアクセストークン取得処理を追加
users.serviceにユーザ追加処理を追加
user.entityにauto_renew、license_alert、notificationを追加
users.repository.serviceにユーザ追加・AuthorId検索処理を追加

## レビューポイント
処理の記載場所が適切かどうか
期待通りの処理になっているかどうか
テストコードの記載方法が正しいかどうか

## UIの変更
なし

## 動作確認状況
ローカルでのビルド・実行を確認

## 補足
テスト実装について不安要素があります。
・テストの粒度はこれでよいのでしょうか？
・テスト実行に４０分かかってしまうのですが実装方法を間違えている箇所がありそうでしょうか？
 2023-05-11 09:05:54 +00:00
maruyama.t
d297301212 Merged PR 82: API実装（メール認証） 
## 概要
[Task1594: API実装（メール認証）](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/1594)

- メール認証APIを作成
- src/api/common/にpasswordを追加（ランダムパスワード発行ロジック）
- src/fuatures/gateway/adb2c.service.tsにユーザのパスワードを変更するメソッドchangePasswordを追加
- user.service.spec.tsにメール認証と仮パスワード発行のテストケースを追加
- 影響範囲
（user.service.spec.tsで行っていた既存のテストケース）

## レビューポイント
- commonにpasswordを追加したが、配置として適切かどうか
- user.service.tsのエラー発生時のロジックが十分であるか

## 動作確認状況
- ローカルで確認
 2023-05-11 07:45:30 +00:00
makabe.t
b3ab401cbc Merged PR 90: 全体見直しをかけ、レビュー依頼する 
## 概要
[Task1677: 全体見直しをかけ、レビュー依頼する](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/1677)

- 外部連携API IFについて見直し、各APIに説明を追加しました。
  - ユーザー情報取得API
  - 認証情報再生成API
  - 音声ファイルアップロード完了API（タスク追加API）
  - ステータス変更API
    - チェックアウト
    - チェックイン
    - キャンセル
    - 中断
    - 差し戻し
    - バックアップ
  - テンプレートファイルダウンロード先取得API
  - 次ファイル情報取得API
  - 音声ファイル、タスク情報取得API
  - 認証情報生成API

## レビューポイント
- 外部連携API IFの実装としても漏れはないか
- 各APIの説明は適切か
- 各APIのパス、パラメータは適切か
- API間で文言の統一はできているか

## UIの変更
無し

## 動作確認状況
- ローカルで確認
 2023-05-08 08:26:24 +00:00
makabe.t
8a0815821e Merged PR 85: IF実装(ユーザー情報取得API/音声ファイルアップロード完了API) 
## 概要
[Task1644: IF実装(ユーザー情報取得API/音声ファイルアップロード完了API)](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/1644)

- 以下の外部連携APIのIFを実装しました。
  - ユーザー情報取得API
  - 音声ファイルアップロード完了API

## レビューポイント
- 音声ファイルアップロード完了APIについてTaskフォルダを掘って新規に追加したがフォルダ構成に問題はないか。
- IFの応答ステータスは適切か。
- リクエスト/レスポンスは想定通りか
  - ユーザー情報取得API応答のWorkTypeID周りが不安なのでご確認をお願いします。

## UIの変更
- なし

## 動作確認状況
- Swaggerをローカルで確認
 2023-04-24 09:58:25 +00:00
湯本 開
6a5926ab3f Merged PR 70: API I/F実装（メール認証） 
## 概要
[Task1599: API I/F実装（メール認証）](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/1599)

- エンドユーザーのメール認証を行うAPIのI/Fを作成

## レビューポイント
- pathは問題なさそうか
- Request/Responseは本質的に同一だと思われるため、管理者の認証と共通としたが問題ないか？

## 動作確認状況
- openapi.jsonの生成を確認
 2023-04-12 04:36:20 +00:00
湯本 開
bfa7fc4f76 Merged PR 68: API実装（I/F） 
## 概要
[Task1590: API実装（I/F）](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/1590)

- ラフスケッチを元にAPI I/Fを実装し、openapi.jsonを生成
- ラフスケッチ時はユーザー登録のリクエストに `authorMetadata` のような拡張可能な形式で考えていた部分を、単に煩雑になるだけと判断して素のAuthorID/TypistGroupIDに変更
- `@POST()/@GET()` の定義箇所をメソッド定義が書かれている行に近づけるよう修正

# レビュー対象外
- メール認証APIは[別Task](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/OMDSDictation/_workitems/edit/1599)に分割してそちらで対応予定のため今回は未実装

## レビューポイント
- 認証情報の取り方は `@Req()` と `@Body()` を両方引数に定義する方法で問題なさそうか
- ラフスケッチ時からリクエストボディの構造が変わったが問題ないか
- APIの引数の型などは問題ないか

## 動作確認状況
- ビルドが通ることを確認
 2023-04-11 04:03:33 +00:00
makabe.t
bd4aaa8ae1 Merged PR 63: API実装（メール認証） 
## 概要
[Task1497: API実装（メール認証）](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/1497)

- メール認証APIとテストを実装しました。

- IDトークンの型を現状と合わせて修正しました
  - `family_name`と`given_name`を削除しました。
- auth.serviceのテストも併せて修正しました。
  - テストケースのIDトークンを環境変数の鍵で生成するように修正しました。

## レビューポイント
- DBのユーザを検証済みにする処理について、トランザクション内で取得と更新をしていますがトランザクションの使い方として問題ないでしょうか？
- 本APIで使用するカスタムエラーを`common/error/types`に暫定的においていますがどこに配置するのが適切でしょうか？
  - `common/error/types`に配置する、もしくは`common`配下にカスタムエラー用のフォルダを作成してその下に配置するのが良いかと考えています。
- テストのモックでエラーを発生させる際に、テストケース内でエラーを設定していますがモックファイル内でエラー用のモックを設定するべきでしょうか？

## UIの変更
- なし

## 動作確認状況
- ローカルで確認
  - テストが通ることを確認
 2023-04-10 04:44:16 +00:00
湯本 開
dfd9abc1c3 Merged PR 54: API実装（I/F） 
## 概要
[Task1494: API実装（I/F）](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/1494)

- POST /accounts のAPIを実装
- POST /users/confirm のAPIを実装
- 上記APIからopenapiを実装

## レビューポイント
- ラフスケッチ時から変更になった箇所があるが問題ないか
  - ディーラーIDは省略可能かつIDを指定するべきなのでnumber?に型を変更
  - 管理者ユーザー用に同意済み利用規約バージョンを受け付けるようにした
  - reCAPTCHAを想定して事前にreCAPTCHA用トークンを受け付けるようにした

## 動作確認状況
- openapiが生成されることを確認
 2023-03-23 07:56:18 +00:00