Conversation
Walkthroughマイクロレポートに Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Browser as ブラウザ
participant UsersCtrl as Users::MicroReportsController
participant API as API::MicroReportsController
participant Model as MicroReport
participant Auth as 認可
rect rgb(240,248,255)
Note over Browser,UsersCtrl: 作成フロー（comment_user 設定）
Browser->>UsersCtrl: POST /users/:user/micro_reports
UsersCtrl->>Model: MicroReport.new(params)
UsersCtrl->>UsersCtrl: `@micro_report.comment_user` = current_user
Model->>Model: before_validation → set_default_comment_user (nil時 user代入)
UsersCtrl->>Model: save
UsersCtrl-->>Browser: 成功/失敗レスポンス
end
rect rgb(255,250,240)
Note over Browser,UsersCtrl: 削除フロー（comment_user に基づく認可）
Browser->>UsersCtrl: DELETE /users/:user/micro_reports/:id
UsersCtrl->>Auth: check current_user.admin? OR micro_report.comment_user == current_user
alt 許可
UsersCtrl->>Model: destroy
UsersCtrl-->>Browser: リダイレクト/通知
else 拒否
UsersCtrl-->>Browser: alert でリダイレクト
end
end
rect rgb(245,255,245)
Note over Browser,API: API 側の検索スコープ変更（非管理者）
Browser->>API: GET/DELETE /api/micro_reports/:id
API->>API: if admin → MicroReport.find(id)
API->>API: else → current_user.authored_micro_reports.find(id)
API-->>Browser: response
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 注目ポイント:
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
nakamu-kazu222
requested review from
kutimiti1234
and removed request for
komagata
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/controllers/users/micro_reports_controller.rb (1)
46-48:set_micro_reportのクエリロジックが新機能と整合していません。現在の実装では、非管理者の場合
current_user.micro_reportsから検索していますが、これはuser_idがcurrent_user.idのレコードのみを対象とします。新機能では、ユーザーは他のユーザーの分報ページに自分がコメントを投稿でき、そのコメントを削除できる必要があります。しかし、現在のロジックでは
comment_user_id = current_user.idのレコードが取得できないため、他のユーザーの分報ページで自分が書いたコメントを削除できません。以下の修正を適用してください:
def set_micro_report - @micro_report = current_user.admin? ? MicroReport.find(params[:id]) : current_user.micro_reports.find(params[:id]) + if current_user.admin? + @micro_report = MicroReport.find(params[:id]) + else + @micro_report = MicroReport.where(id: params[:id]) + .where('user_id = ? OR comment_user_id = ?', current_user.id, current_user.id) + .first! + end end
🧹 Nitpick comments (4)
app/models/micro_report.rb (1)
7-7:comment_userのバリデーションを追加することを検討してください。
belongs_toはデフォルトでoptional: falseですが、明示的なpresenceバリデーションを追加することで意図がより明確になります。belongs_to :user belongs_to :comment_user, class_name: 'User' validates :content, presence: true +validates :comment_user, presence: truedb/migrate/20251002152627_add_comment_users_to_micro_reports.rb (1)
3-4: インデックスの追加とNULL制約の検討を推奨します。
comment_user_idカラムに対してインデックスが追加されていません。コメントユーザーによる検索や集計クエリが発生する可能性があるため、パフォーマンス向上のためインデックスの追加を推奨します。また、NULL制約についても検討が必要です。コントローラーの実装（line 17）では必ず
comment_userが設定されていますが、既存データのマイグレーション戦略が必要です。以下の修正を検討してください:
def change add_column :micro_reports, :comment_user_id, :bigint + add_index :micro_reports, :comment_user_id add_foreign_key :micro_reports, :users, column: :comment_user_id end既存データのバックフィル（例:
comment_user_idをuser_idと同じ値で埋める）を行った後、別マイグレーションでNOT NULL制約を追加することも検討してください。test/components/users/micro_reports/micro_report_component_test.rb (2)
11-21: フィクスチャデータのcomment_user設定を明示的に行うことを推奨します。Line 13で
micro_report.comment_user ||= micro_report.userという防御的コードを使用していますが、これはフィクスチャにcomment_userが設定されていない場合の対処です。テストの明確性のため、
test/fixtures/micro_reports.ymlで:hajime_first_micro_reportに明示的にcomment_userを設定し、この防御的コードを削除することを検討してください。
44-49: コメントユーザーのアイコン・名前表示の検証を追加することを推奨します。このテストは
comment_userが投稿者と異なる場合の基本的な動作を確認していますが、正しいユーザー（@other_user）のアイコンや名前が表示されているかの検証がありません。以下の検証を追加することを検討してください:
def test_comment_user_is_not_post_owner micro_report = MicroReport.create!(user: @user, comment_user: @other_user, content: '他人のコメント') render_component(micro_report) assert_selector '.micro-report__body', text: '他人のコメント' + assert_selector "img.micro-report_user-icon[title='#{@other_user.icon_title}']" end
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
app/components/users/micro_reports/micro_report_component.html.slim(1 hunks)app/components/users/micro_reports/micro_report_component.rb(2 hunks)app/controllers/users/micro_reports_controller.rb(2 hunks)app/models/micro_report.rb(1 hunks)app/models/user.rb(1 hunks)app/views/users/micro_reports/index.html.slim(1 hunks)db/fixtures/micro_reports.yml(1 hunks)db/migrate/20251002152627_add_comment_users_to_micro_reports.rb(1 hunks)db/schema.rb(3 hunks)test/components/users/micro_reports/micro_report_component_test.rb(1 hunks)test/fixtures/micro_reports.yml(1 hunks)test/system/user/micro_reports_test.rb(0 hunks)
💤 Files with no reviewable changes (1)
- test/system/user/micro_reports_test.rb
🧰 Additional context used
📓 Path-based instructions (2)
test/**/*
⚙️ CodeRabbit configuration file
test/**/*: # Test
- TestCase名は英語で書く。
- どうしても避けられない時以外にsystem testでsleepは使わない。
Unit Test
model, helper, decorator, view_componentについてはメソッドを追加した場合は必ず対応したUnit TestのTestCaseを1つは書く。
Files:
test/fixtures/micro_reports.ymltest/components/users/micro_reports/micro_report_component_test.rb
**/*.rb
⚙️ CodeRabbit configuration file
**/*.rb: # refactoring
- まずFat Controllerを避け、次にFat Modelを避ける。
- Serviceクラスの乱用を避ける。
- controller concernを作ろうとしたらPORO(Plain Old Ruby Object)やActiveRecordモデルでの実装で代替できないか検討する。
Rails Patterns
- ViewHelperにメソッドを実装する時にはまずDecoratorパターンを使うことを検討する。（active_decorator gemを導入しているのでそれを使う）
- 複雑なActiveRecordクエリがあり、再利用できそうな場合はQueryObjectパターンを検討する。（rails-patterns gemを導入しているのでそれのQuery機能を使う）
- Viewにpartialを作る場合はViewComponentを使うことを検討する。
- 複数のActiveRecordモデルを操作する１つの責務がある時や外部APIとやりとりする処理がある場合にはInteractorオブジェクトパターンを検討する。（interactor gemを導入しているのでそれを使う）
- 複数のInteractorを実行するような処理がある場合Organizerオブジェクトパターンを検討する。（interactor gemを導入しており、その中にOrganizerの機能があるので使う）
Files:
app/components/users/micro_reports/micro_report_component.rbapp/models/user.rbtest/components/users/micro_reports/micro_report_component_test.rbdb/migrate/20251002152627_add_comment_users_to_micro_reports.rbapp/models/micro_report.rbdb/schema.rbapp/controllers/users/micro_reports_controller.rb
🧠 Learnings (1)
📚 Learning: 2025-07-23T20:31:13.856Z
Learnt from: jun-kondo
PR: fjordllc/bootcamp#8977
File: app/controllers/reports_controller.rb:63-63
Timestamp: 2025-07-23T20:31:13.856Z
Learning: fjordllc/bootcampプロジェクトの`app/controllers/reports_controller.rb`において、`create`と`update`アクションは両方とも`report.save_uniquely`を使用し、同じ`:report_save`イベントと`'report.save'`イベントを発行する。これは両方とも本質的に「レポートの保存」操作であり、作成と更新を区別する必要がないためである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
🧬 Code graph analysis (3)
test/components/users/micro_reports/micro_report_component_test.rb (2)
app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)app/decorators/user_decorator.rb (1)
icon_title(14-17)
app/models/micro_report.rb (1)
app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)
app/controllers/users/micro_reports_controller.rb (1)
app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)
🪛 YAMLlint (1.37.1)
db/fixtures/micro_reports.yml
[error] 20-20: syntax error: could not find expected ':'
(syntax)
🔇 Additional comments (8)
app/views/users/micro_reports/index.html.slim (1)
11-11: コントローラー側の認可ロジックを確認してください。フォームの表示条件を
current_user == @userからcurrent_userに変更し、すべてのログインユーザーが投稿できるようになりました。コントローラーのcreateアクションで適切にcomment_userが設定され、destroyアクションで適切な認可チェック（投稿者本人または管理者のみ削除可能）が実装されていることを確認してください。※レビュー対象ファイルにコントローラーが含まれていないため、実装を確認できませんでした。
app/components/users/micro_reports/micro_report_component.rb (2)
10-12: LGTM!
comment_userメソッドの実装は明確で適切です。
25-27: Unit Testの追加を確認してください。コーディングガイドラインに従い、view_componentにメソッドを追加した場合は対応するUnit Testが必要です。
owner_post?メソッドの動作を検証するテストケースが追加されていることを確認してください。具体的には以下のケースをテストすることを推奨します：
comment_userが@userと同じ場合、trueを返すことcomment_userが@userと異なる場合、falseを返すことBased on coding guidelines
app/components/users/micro_reports/micro_report_component.html.slim (3)
3-3: LGTM!ユーザーアイコンの表示を
comment_userに変更し、コメント投稿者を正しく表示するようになりました。
8-9: LGTM!リンクとユーザー名の表示を
comment_userに変更し、コメント投稿者の情報を正しく表示するようになりました。
17-17: LGTM!認可ロジックが適切に実装されています。コメント投稿者本人または管理者のみが編集・削除ボタンを表示できるようになっており、PRの目的に沿った実装です。
app/controllers/users/micro_reports_controller.rb (1)
16-19: 他のユーザーの分報へのコメント投稿を正しく実装しています。
comment_userをcurrent_userに設定し、分報の所有者チェックを削除することで、意図通り他のユーザーの分報にもコメントできるようになっています。test/components/users/micro_reports/micro_report_component_test.rb (1)
23-42: 明示的なcomment_userの設定により、テストの意図が明確になっています。各テストで
userとcomment_userの両方を明示的に設定することで、テストの前提条件が明確になり、可読性が向上しています。
| def set_default_comment_user | ||
| self.comment_user ||= user | ||
| end |
There was a problem hiding this comment.
Unit Testの追加が必要です。
コーディングガイドラインに従い、modelにメソッドを追加した場合は対応するUnit Testを書く必要があります。set_default_comment_userコールバックの動作を検証するテストケースを追加してください。
具体的には、以下のケースをテストすることを推奨します：
comment_userが未設定の場合、userが自動設定されることcomment_userが既に設定されている場合、上書きされないこと
Based on coding guidelines
🤖 Prompt for AI Agents
In app/models/micro_report.rb around lines 14 to 16, there is a new callback
method set_default_comment_user but no accompanying unit tests; add RSpec model
specs (e.g. spec/models/micro_report_spec.rb) that cover: (1) when comment_user
is nil on create, the callback sets comment_user to the report's user, and (2)
when comment_user is already set before save, the callback does not overwrite
it. Use FactoryBot to build/create MicroReport records to trigger the callback
(create to persist), stub or assign users as needed, and assert the final
comment_user matches expected values in each case.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find test files for MicroReport model
fd -e rb "micro_report" test/ spec/
Length of output: 233
🏁 Script executed:
#!/bin/bash
# Look for model test files specifically
fd -t f "micro_report.*test.rb" test/models/
fd -t f "micro_report.*spec.rb" spec/models/
Length of output: 132
🏁 Script executed:
#!/bin/bash
# Check if there's a test/models directory and list its contents
if [ -d "test/models" ]; then
ls -la test/models/ | grep micro
fi
# Check if there's a spec/models directory
if [ -d "spec/models" ]; then
ls -la spec/models/ | grep micro
fi
Length of output: 71
🏁 Script executed:
#!/bin/bash
# Search for any test files that might test the set_default_comment_user method
rg -n "set_default_comment_user" test/ spec/ 2>/dev/null || echo "No matches found"
Length of output: 16
🏁 Script executed:
#!/bin/bash
# Check for micro_report model tests in the entire test directory
rg -l "class.*MicroReport" test/ 2>/dev/null | head -5
Length of output: 240
🏁 Script executed:
#!/bin/bash
# Check the content of the MicroReport model test file
cat test/models/micro_report_test.rb
Length of output: 681
@nakamu-kazu222 さん、修正ありがとうございます！
test/models/micro_report_test.rb にて、set_default_comment_user コールバックの動作を検証する2つのテストケースが適切に追加されていることを確認しました：
✅ comment_user が未設定の場合、user が自動設定されること
✅ comment_user が既に設定されている場合、上書きされないこと
両方のケースがカバーされており、問題ありません！
🧬 Code Graph Analysis Results
-
File: app/components/users/micro_reports/micro_report_component.rb
- Snippet (lines 10-12):
def comment_user
@micro_report.comment_user
end
- Snippet (lines 10-12):
-
File: app/models/user.rb
-
Summary (lines 3-988):
Relevant associations:- has_many :micro_reports, dependent: :destroy
- Defines that a User has many MicroReport records authored as the normal user.
- has_many :authored_micro_reports, class_name: 'MicroReport', foreign_key: 'comment_user_id', dependent: :destroy, inverse_of: :comment_user
- Defines that a User may be the comment_user (i.e., the commenter) on MicroReport records, linking via the comment_user_id foreign key. This inverse relation complements MicroReport#comment_user.
These associations help understand how a MicroReport is linked to a User both as the author and as the commenter referenced by comment_user_id.
- has_many :micro_reports, dependent: :destroy
-
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
app/controllers/users/micro_reports_controller.rb (1)
46-54: 削除認可が破綻しています（読み込み対象とフィルタの停止方法）
- 問題1:
set_micro_reportが「投稿オーナーの分報」に限定して検索しているため、コメント作成者（オーナー以外）が自分のコメントを削除できません。一方、オーナーは他人のコメントも取得できてしまいます（要件違反）。- 問題2:
authorize_micro_report!はredirect_toのみで終了しており、アクション実行が停止しません。結果として、権限がないユーザーでもdestroyが実行され得ます。以下の修正で解消してください。
- def set_micro_report - @micro_report = current_user.admin? ? MicroReport.find(params[:id]) : current_user.micro_reports.find(params[:id]) - end + def set_micro_report + # 認可はauthorize_micro_report!で実施。ここでは無条件で対象をロード + @micro_report = MicroReport.find(params[:id]) + end @@ - def authorize_micro_report! - return if current_user.admin? || @micro_report.comment_user == current_user - - redirect_to user_micro_reports_path(@user), alert: '権限がありません。' - end + def authorize_micro_report! + return if current_user&.admin? || @micro_report.comment_user == current_user + redirect_to(user_micro_reports_path(@user), alert: '権限がありません。') and return + # もしくは head :forbidden / raise 例外 などで明確に停止 + endあわせて、削除後のリダイレクトは
redirect_to ..., notice: '分報を削除しました。'のオプション引数で書くと意図が明確になります（任意）。
🧹 Nitpick comments (3)
test/models/micro_report_test.rb (2)
10-15: テストはOK。失敗時に即座に検知できるようにしましょう
.saveではなく.save!（または最初から.create!）を使うと、バリデーション失敗を取りこぼしません。- micro_report = MicroReport.new(user:, content: 'テスト') - micro_report.save + micro_report = MicroReport.create!(user:, content: 'テスト')
17-23: 指定済みcomment_userの保持テストも良いです同様に
.create!に揃えてテストの堅牢性を上げましょう。- micro_report = MicroReport.new(user:, comment_user: other_user, content: 'テスト') - micro_report.save + micro_report = MicroReport.create!(user:, comment_user: other_user, content: 'テスト')app/components/users/micro_reports/micro_report_component.rb (1)
25-27:owner_post?の命名が意図とズレます（未使用なら削除推奨）実体は「オーナー自身が書いたコメントか？」の判定です。未使用なら削除、使用するなら
authored_by_owner?などに改名を検討してください。
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
app/components/users/micro_reports/micro_report_component.html.slim(1 hunks)app/components/users/micro_reports/micro_report_component.rb(2 hunks)app/controllers/users/micro_reports_controller.rb(2 hunks)app/models/user.rb(1 hunks)test/components/users/micro_reports/micro_report_component_test.rb(1 hunks)test/models/micro_report_test.rb(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.rb
⚙️ CodeRabbit configuration file
**/*.rb: # refactoring
- まずFat Controllerを避け、次にFat Modelを避ける。
- Serviceクラスの乱用を避ける。
- controller concernを作ろうとしたらPORO(Plain Old Ruby Object)やActiveRecordモデルでの実装で代替できないか検討する。
Rails Patterns
- ViewHelperにメソッドを実装する時にはまずDecoratorパターンを使うことを検討する。（active_decorator gemを導入しているのでそれを使う）
- 複雑なActiveRecordクエリがあり、再利用できそうな場合はQueryObjectパターンを検討する。（rails-patterns gemを導入しているのでそれのQuery機能を使う）
- Viewにpartialを作る場合はViewComponentを使うことを検討する。
- 複数のActiveRecordモデルを操作する１つの責務がある時や外部APIとやりとりする処理がある場合にはInteractorオブジェクトパターンを検討する。（interactor gemを導入しているのでそれを使う）
- 複数のInteractorを実行するような処理がある場合Organizerオブジェクトパターンを検討する。（interactor gemを導入しており、その中にOrganizerの機能があるので使う）
Files:
test/models/micro_report_test.rbapp/models/user.rbapp/components/users/micro_reports/micro_report_component.rbapp/controllers/users/micro_reports_controller.rbtest/components/users/micro_reports/micro_report_component_test.rb
test/**/*
⚙️ CodeRabbit configuration file
test/**/*: # Test
- TestCase名は英語で書く。
- どうしても避けられない時以外にsystem testでsleepは使わない。
Unit Test
model, helper, decorator, view_componentについてはメソッドを追加した場合は必ず対応したUnit TestのTestCaseを1つは書く。
Files:
test/models/micro_report_test.rbtest/components/users/micro_reports/micro_report_component_test.rb
🧠 Learnings (1)
📚 Learning: 2025-07-23T20:31:13.856Z
Learnt from: jun-kondo
PR: fjordllc/bootcamp#8977
File: app/controllers/reports_controller.rb:63-63
Timestamp: 2025-07-23T20:31:13.856Z
Learning: fjordllc/bootcampプロジェクトの`app/controllers/reports_controller.rb`において、`create`と`update`アクションは両方とも`report.save_uniquely`を使用し、同じ`:report_save`イベントと`'report.save'`イベントを発行する。これは両方とも本質的に「レポートの保存」操作であり、作成と更新を区別する必要がないためである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
🧬 Code graph analysis (3)
test/models/micro_report_test.rb (2)
test/components/users/micro_reports/micro_report_component_test.rb (2)
setup(5-78)setup(6-9)app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)
app/controllers/users/micro_reports_controller.rb (1)
app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)
test/components/users/micro_reports/micro_report_component_test.rb (2)
app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)app/decorators/user_decorator.rb (1)
icon_title(14-17)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build_and_test
🔇 Additional comments (10)
app/models/user.rb (1)
133-133:authored_micro_reportsの追加は妥当です
foreign_key,inverse_of,dependent: :destroyの指定は新しい所有権モデルに整合しています。DBレベルでもmicro_reports.comment_user_idに外部キーがあり、必要ならON DELETE CASCADE相当の整合性が取れているかだけ確認してください。app/components/users/micro_reports/micro_report_component.html.slim (3)
3-3: 表示主体をcomment_userに切替は適切ですアイコンの出所がコメント作成者になり、要件どおりです。
8-9: プロフィールリンクとログイン名の切替も整合
link_to user_path(comment_user)とcomment_user.login_nameへの置換は一貫しています。
16-17: 編集/削除ボタンの可視条件が要件に一致
@micro_report.comment_user == @current_user || @current_user&.admin?での制御は適切です。この可視条件に対応するコントローラ側の認可も一致しているか（後述の修正）をあわせてご確認ください。
app/components/users/micro_reports/micro_report_component.rb (1)
10-12:comment_userアクセサの公開は妥当テンプレートからの参照用途としてシンプルでOKです。
app/controllers/users/micro_reports_controller.rb (1)
17-19: 作成時のcomment_user強制上書きは適切ですパラメータ偽装を防げます。このままでOK。
test/components/users/micro_reports/micro_report_component_test.rb (4)
6-9: LGTM!複数ユーザーでのテストシナリオに必要な
@other_userの追加は適切です。
51-66: LGTM! 管理者のテストケースが追加されました。以前のレビューコメントで要望されていた管理者ユーザーのテストケースが適切に追加されています。3つのシナリオ（投稿者、コメント作成者、管理者）すべてが正しくカバーされており、編集・削除ボタンの表示ロジックが適切にテストされています。
70-77: LGTM!
current_userパラメータの追加により、認可ロジックのテストが可能になっています。デフォルト値の設定により既存のテストとの互換性も保たれています。
11-21: フィクスチャの確認を進めます。Model実装の確認が必要です。
重要な情報が得られました。フィクスチャはコールバックをトリガーしません。なぜなら、モデルを毎回インスタンス化しないためです。一方、ファクトリはコールバックをトリガーします。
MicroReport モデルの実装を確認します。
Now I have sufficient evidence to rewrite the review comment. The web search results clearly show that fixtures bypass the normal Active Record object creation process, are inserted directly into the database using insert queries, and skip callbacks and validations. Combined with the fixture output showing
comment_useris properly set in the YAML, the defensive assignment is unnecessary.Line 13の防御的な代入は不要です。
Railsのフィクスチャは通常のActive Recordオブジェクト作成プロセスをバイパスし、YAMLファイルから直接データベースに挿入されるため、コールバックと検証をスキップします。フィクスチャファイルで
comment_user: hajimeが既に設定されているため、micro_report.comment_user ||= micro_report.userという防御的コードは不要です。before_validationコールバックはフィクスチャ読み込み時には実行されないため、フィクスチャから直接読み込まれた値がそのまま使用可能になります。この防御的コードを削除してください。
| def test_comment_user_is_not_post_owner | ||
| micro_report = MicroReport.create!(user: @user, comment_user: @other_user, content: '他人のコメント') | ||
| render_component(micro_report) | ||
|
|
||
| assert_selector '.micro-report__body', text: '他人のコメント' | ||
| end |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
コメントユーザーのアイコンと名前の表示を検証するアサーションを追加してください。
このテストはコメント投稿者が分報の所有者と異なる重要なシナリオをカバーしていますが、本文の表示のみを検証しています。コンポーネントが正しくcomment_userのアイコンとユーザー情報を表示していることを確認するアサーションを追加すべきです。
以下のdiffを適用してテストを強化してください:
def test_comment_user_is_not_post_owner
micro_report = MicroReport.create!(user: @user, comment_user: @other_user, content: '他人のコメント')
render_component(micro_report)
+ assert_selector "img.micro-report_user-icon[title='#{@other_user.icon_title}']"
assert_selector '.micro-report__body', text: '他人のコメント'
end📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| def test_comment_user_is_not_post_owner | |
| micro_report = MicroReport.create!(user: @user, comment_user: @other_user, content: '他人のコメント') | |
| render_component(micro_report) | |
| assert_selector '.micro-report__body', text: '他人のコメント' | |
| end | |
| def test_comment_user_is_not_post_owner | |
| micro_report = MicroReport.create!(user: @user, comment_user: @other_user, content: '他人のコメント') | |
| render_component(micro_report) | |
| assert_selector "img.micro-report_user-icon[title='#{@other_user.icon_title}']" | |
| assert_selector '.micro-report__body', text: '他人のコメント' | |
| end |
🤖 Prompt for AI Agents
In test/components/users/micro_reports/micro_report_component_test.rb around
lines 44 to 49, the test verifies only the comment body but not that the
component displays the comment_user's avatar and name; add assertions after
render_component to assert the presence of the comment user's avatar element
(e.g., an img or .avatar selector with src or alt matching @other_user) and an
assertion that the comment user's name or link (e.g., text of @other_user.name
or a selector like .user-name/.micro-report__user a) is rendered so the
component confirms the comment_user's icon and user info are shown.
There was a problem hiding this comment.
@nakamu-kazu222 修正を確認しました!👍
comment_userのアイコン表示を検証するアサーションが追加され、テストがより堅牢になりました。これで、コンポーネントが正しく@other_userのアイコンを表示していることを確認できます。
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
|
お疲れ様です🙏 何かご不明点やご指摘がございましたら、お知らせください |
|
@nakamu-kazu222 |
|
お疲れ様です！ |
| before_action :set_micro_report, only: %i[destroy] | ||
| before_action :authorize_micro_report!, only: %i[destroy] |
There was a problem hiding this comment.
@nakamu-kazu222
ここ、destroy でしか実行されないのであれば action 内に直接記述した方がよいかと思うのですがいかがでしょうか〜
コールバックを使うと、読み手がコードを読むときのコストが少し上がってしまいます。
（行ったり来たりしなくてはならないので）
また、書き手の意図しない挙動になる可能性も上がります。
ので、コールバックの利用が必要な場面かどうかは、一度立ち止まって考えてみるといいかなと思います！
There was a problem hiding this comment.
あ！ @kutimiti1234 さんがレビューする前に口出しちゃった！！
ごめんなさい！！！！！！
There was a problem hiding this comment.
tadakiさん nakamu-kazu222さん
こちらこそレビューが遅れており申し訳ございません。
今日明日までには返したいと思います
There was a problem hiding this comment.
@torinoko さん cc: @kutimiti1234 さん
レビューいただきありがとうございました！
ご指摘の通りで、今回の実装ではbefore_action でdestroyしか実行されないのでaction内に直接記述しました
|
commit単位が作業ログのようになっていることが気になりました。 |
|
@nakamu-kazu222 |
kutimiti1234
left a comment
kutimiti1234
left a comment
There was a problem hiding this comment.
kensyuでログインして、kimuraの分報にコメントした場合、kensyuが自分で投稿したコメントを削除できないです。
下記で指摘されているものになります。
#9260 (review)
また、他のユーザーが他のユーザー自身のコメントを削除できるかのテストが見受けられないです。
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
app/controllers/api/micro_reports_controller.rb(1 hunks)app/controllers/users/micro_reports_controller.rb(3 hunks)app/views/users/micro_reports/index.html.slim(1 hunks)test/system/user/micro_reports_test.rb(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- app/views/users/micro_reports/index.html.slim
🧰 Additional context used
📓 Path-based instructions (2)
**/*.rb
⚙️ CodeRabbit configuration file
**/*.rb: # refactoring
- まずFat Controllerを避け、次にFat Modelを避ける。
- Serviceクラスの乱用を避ける。
- controller concernを作ろうとしたらPORO(Plain Old Ruby Object)やActiveRecordモデルでの実装で代替できないか検討する。
Rails Patterns
- ViewHelperにメソッドを実装する時にはまずDecoratorパターンを使うことを検討する。（active_decorator gemを導入しているのでそれを使う）
- 複雑なActiveRecordクエリがあり、再利用できそうな場合はQueryObjectパターンを検討する。（rails-patterns gemを導入しているのでそれのQuery機能を使う）
- Viewにpartialを作る場合はViewComponentを使うことを検討する。
- 複数のActiveRecordモデルを操作する１つの責務がある時や外部APIとやりとりする処理がある場合にはInteractorオブジェクトパターンを検討する。（interactor gemを導入しているのでそれを使う）
- 複数のInteractorを実行するような処理がある場合Organizerオブジェクトパターンを検討する。（interactor gemを導入しており、その中にOrganizerの機能があるので使う）
Files:
app/controllers/api/micro_reports_controller.rbapp/controllers/users/micro_reports_controller.rbtest/system/user/micro_reports_test.rb
test/**/*
⚙️ CodeRabbit configuration file
test/**/*: # Test
- TestCase名は英語で書く。
- どうしても避けられない時以外にsystem testでsleepは使わない。
Unit Test
model, helper, decorator, view_componentについてはメソッドを追加した場合は必ず対応したUnit TestのTestCaseを1つは書く。
Files:
test/system/user/micro_reports_test.rb
🧠 Learnings (8)
📓 Common learnings
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/models/graduation_notifier.rb:23-28
Timestamp: 2025-09-12T21:16:47.639Z
Learning: Rails upgrade PRにおいて、configuration systemの変更やwebhook設定の改善提案も、アップグレードに直接関連しない場合は別PRで対応すべきである。PRのスコープ維持が重要。
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:131-135
Timestamp: 2025-09-12T21:18:00.834Z
Learning: Rails アップグレードPRにおいて、product_review_not_completed メソッドの webhook URL 設定の shared フォールバック追加も、設定システム全体の変更として別PRで対応すべきである。
📚 Learning: 2025-07-23T20:31:13.856Z
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 8977
File: app/controllers/reports_controller.rb:63-63
Timestamp: 2025-07-23T20:31:13.856Z
Learning: fjordllc/bootcampプロジェクトの`app/controllers/reports_controller.rb`において、`create`と`update`アクションは両方とも`report.save_uniquely`を使用し、同じ`:report_save`イベントと`'report.save'`イベントを発行する。これは両方とも本質的に「レポートの保存」操作であり、作成と更新を区別する必要がないためである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-12T21:17:26.029Z
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:19-23
Timestamp: 2025-09-12T21:17:26.029Z
Learning: Rails アップグレードPRにおいて、config_for(:secrets) を使った webhook URL 設定の shared セクション未参照問題は、設定システム全体の変更として別PRで対応すべきである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-12T21:18:00.834Z
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:131-135
Timestamp: 2025-09-12T21:18:00.834Z
Learning: Rails アップグレードPRにおいて、product_review_not_completed メソッドの webhook URL 設定の shared フォールバック追加も、設定システム全体の変更として別PRで対応すべきである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-01T22:31:57.345Z
Learnt from: matuaya
Repo: fjordllc/bootcamp PR: 9108
File: app/models/after_user_retirement.rb:0-0
Timestamp: 2025-09-01T22:31:57.345Z
Learning: fjordllc/bootcampプロジェクトにおいて、`Newspaper.publish(:retirement_create, { user: user })`はUnfinishedDataDestroyer（未チェックProduct・WIP Report削除、career_pathリセット）とTimesChannelDestroyer（Discord分報チャンネル削除）による重要なデータクリーンアップ処理を実行するため、退会のトリガーが何であろうと（admin、hibernation、user）必ず実行する必要がある。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-01T22:31:57.345Z
Learnt from: matuaya
Repo: fjordllc/bootcamp PR: 9108
File: app/models/after_user_retirement.rb:0-0
Timestamp: 2025-09-01T22:31:57.345Z
Learning: fjordllc/bootcampプロジェクトにおいて、`Newspaper.publish(:retirement_create, { user: user })`は通知処理ではなく、UnfinishedDataDestroyerやTimesChannelDestroyer等による重要なデータクリーンアップ処理を実行するため、管理者による退会（triggered_by: 'admin'）の場合でも必ず実行する必要がある。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-07-23T21:11:21.826Z
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 0
File: :0-0
Timestamp: 2025-07-23T21:11:21.826Z
Learning: fjordllc/bootcampプロジェクトの`app/models/work_notification_destroyer.rb`において、このクラスは`app/controllers/works_controller.rb`の`destroy`アクションから呼び出され、`before_action :set_my_work`でIDの妥当性チェックが事前に行われるため、payloadのworkオブジェクトは常に有効であることが保証されている。そのためエラーハンドリングは不要。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-07-15T04:26:24.899Z
Learnt from: masyuko0222
Repo: fjordllc/bootcamp PR: 8934
File: app/controllers/test_feature_toggle_controller.rb:4-6
Timestamp: 2025-07-15T04:26:24.899Z
Learning: テスト用の一時的なコードで、すぐにリバートされる予定の場合、nil安全性などの防御的プログラミングの実装は不要とされることがある。
Applied to files:
app/controllers/users/micro_reports_controller.rb
🧬 Code graph analysis (2)
app/controllers/users/micro_reports_controller.rb (1)
app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)
test/system/user/micro_reports_test.rb (1)
app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build_and_test
🔇 Additional comments (4)
app/controllers/api/micro_reports_controller.rb (1)
16-23: 認可ロジックの変更が正しく実装されています。
micro_reportsからauthored_micro_reportsへの変更により、ユーザーは自分が作成したマイクロレポート（コメント）のみを更新できるようになっています。これはPRの目的（他のユーザーの分報にコメント可能だが、編集は作成者のみ）と一致しており、管理者によるバイパスも適切です。また、三項演算子から if-else ブロックへの展開により可読性が向上しています。
app/controllers/users/micro_reports_controller.rb (2)
14-25: LGTM! 分報のコメント投稿機能が正しく実装されています。
comment_userへの代入と、オーナーのみチェックの削除により、他のユーザーも分報にコメントできるようになっています。PRの目的に沿った実装です。
47-54: 防御的な実装で適切です。管理者以外のユーザーが
authored_micro_reportsからのみ検索できるようにすることで、多層防御を実現しています。Line 28の認可チェックと合わせて、セキュリティが確保されています。この実装により、権限のないユーザーがアクセスしようとした場合、リソースの存在を明かさない404エラーになります。これはセキュリティ上望ましい動作です。
test/system/user/micro_reports_test.rb (1)
144-160: LGTM! 新機能のテストが適切に実装されています。コメント投稿者が他のユーザーの分報ページで自分のコメントを削除できることを正しくテストしています。テストケース名も英語で記述されており、コーディングガイドラインに準拠しています。
| redirect_to user_micro_reports_path(@user), alert: '権限がありません。' and return unless current_user.admin? || @micro_report.comment_user == current_user | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
認可処理の書き方を改善し、既存データの考慮を確認してください。
現在の実装は動作しますが、以下の点を検討してください：
- より読みやすい記法:
and return unlessの組み合わせは動作しますが、可読性の観点から以下のいずれかの記法を推奨します：
# パターン1: unless ブロック
unless current_user.admin? || @micro_report.comment_user == current_user
redirect_to user_micro_reports_path(@user), alert: '権限がありません。'
return
end# パターン2: 早期リターン
return redirect_to user_micro_reports_path(@user), alert: '権限がありません。' unless current_user.admin? || @micro_report.comment_user == current_user- 既存データの考慮: この機能追加前に作成された分報は
comment_userがnilの可能性があります。その場合、非管理者ユーザーは自分の古い分報を削除できなくなります。マイグレーションで既存レコードのcomment_userを適切に設定しているか確認してください。
以下のスクリプトで既存のcomment_userがnilのレコードがないか確認できます：
🏁 Script executed:
#!/bin/bash
# Description: Check for micro_reports with null comment_user
# Search for the migration file to verify if it handles existing records
fd -e rb add_comment_users_to_micro_reports db/migrate/
# Look for any data migration or default value setting
rg -A 10 "comment_user" db/migrate/ --type rubyLength of output: 455
---
🏁 Script executed:
```shell
#!/bin/bash
# View full migration file to understand data handling
cat db/migrate/20251002152627_add_comment_users_to_micro_reports.rb
echo "---"
# Check for any seeds or data migrations related to micro_reports
fd -e rb . db/ | xargs grep -l "micro_report" | head -20
echo "---"
# Look at the controller to understand the full context
sed -n '20,45p' app/controllers/users/micro_reports_controller.rb
Length of output: 1015
---
🏁 Script executed:
```shell
#!/bin/bash
# Search for code that populates comment_user_id on existing records
rg "comment_user_id\s*=" --type ruby -B 3 -A 3 | head -50
echo "---"
# Check if there are any rake tasks or background jobs related to micro_reports
fd -e rb . lib/tasks/ app/jobs/ | xargs grep -l "micro_report" 2>/dev/null
echo "---"
# Check MicroReport model for any callbacks that set comment_user
rg "class MicroReport" -A 50 app/models/micro_report.rb
Length of output: 316
既存レコードのcomment_userをマイグレーションで設定してください。
検証結果：問題は実在します。MicroReportモデルのbefore_validation :set_default_comment_user, on: :createは新規作成時のみ動作するため、マイグレーション前の既存レコードはcomment_user_idがNULLのままになります。その結果、非管理者ユーザーは自分の古い分報を削除できなくなります。
必須対応：
-
データマイグレーション追加: 既存の
comment_user_idがNULLのレコードに対して、user_idをセットするマイグレーションを追加してください -
ついでに読みやすい記法に変更 (線28-29):
# 改善案
return redirect_to user_micro_reports_path(@user), alert: '権限がありません。' unless current_user.admin? || @micro_report.comment_user == current_user🤖 Prompt for AI Agents
In app/controllers/users/micro_reports_controller.rb around lines 28-29, update
the redirect line to the clearer form "return redirect_to
user_micro_reports_path(@user), alert: '権限がありません。' unless current_user.admin? ||
@micro_report.comment_user == current_user" (replace the current chained
`redirect_to ... and return unless` usage), and add a Rails migration that
backfills existing MicroReport records by setting comment_user_id = user_id
where comment_user_id IS NULL (a reversible data migration that updates only
NULLs and includes a safety check / transaction).
There was a problem hiding this comment.
マイグレーションを追加しました
また、改善案のreturn redirect_to user_micro_reports_path(@user), alert: '権限がありません。' unless current_user.admin? || @micro_report.comment_user == current_userに変更しました
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find all migration files related to micro_reports to identify the new backfill migration
fd -e rb . db/migrate/ | grep micro_report | sort
echo "---"
# Show the content of any backfill migration (likely the most recent one)
fd -e rb . db/migrate/ | grep micro_report | sort | tail -1 | xargs cat
echo "---"
# Verify the current controller code around the destroy method
sed -n '24,32p' app/controllers/users/micro_reports_controller.rb
Length of output: 796
@nakamu-kazu222 対応ありがとうございます！実装を確認しました。
✅ マイグレーションの追加: BackfillCommentUserIdOnMicroReportsが正しく実装されています
find_eachを使用したバッチ処理で既存のcomment_user_idがNULLのレコードを適切にバックフィルしています- これにより既存の分報も削除可能になります
✅ コードスタイルの改善: 認可処理が推奨された形式に変更されています
return redirect_to user_micro_reports_path(@user), alert: '権限がありません。' unless current_user.admin? || @micro_report.comment_user == current_userどちらの対応も適切です。これで既存データの問題も解決され、コードの可読性も向上しました！🎉
※ 参考: downメソッドで全レコードのcomment_user_idをnilにしていますが、実運用ではロールバックはほぼないため問題ありません。
🧬 Code Graph Analysis Results
- File: app/components/users/micro_reports/micro_report_component.rb (lines 10-12)
def comment_user
@micro_report.comment_user
end
- File: app/models/user.rb (lines 917-919)
def latest_micro_report_page
[micro_reports.page.total_pages, 1].max
end
🧠 Learnings used
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 8977
File: app/controllers/reports_controller.rb:63-63
Timestamp: 2025-07-23T20:31:13.856Z
Learning: fjordllc/bootcampプロジェクトの`app/controllers/reports_controller.rb`において、`create`と`update`アクションは両方とも`report.save_uniquely`を使用し、同じ`:report_save`イベントと`'report.save'`イベントを発行する。これは両方とも本質的に「レポートの保存」操作であり、作成と更新を区別する必要がないためである。
Learnt from: matuaya
Repo: fjordllc/bootcamp PR: 9108
File: app/models/after_user_retirement.rb:0-0
Timestamp: 2025-09-01T22:31:57.345Z
Learning: fjordllc/bootcampプロジェクトにおいて、`Newspaper.publish(:retirement_create, { user: user })`はUnfinishedDataDestroyer（未チェックProduct・WIP Report削除、career_pathリセット）とTimesChannelDestroyer（Discord分報チャンネル削除）による重要なデータクリーンアップ処理を実行するため、退会のトリガーが何であろうと（admin、hibernation、user）必ず実行する必要がある。
Learnt from: matuaya
Repo: fjordllc/bootcamp PR: 9108
File: app/models/after_user_retirement.rb:0-0
Timestamp: 2025-09-01T22:31:57.345Z
Learning: fjordllc/bootcampプロジェクトにおいて、`Newspaper.publish(:retirement_create, { user: user })`は通知処理ではなく、UnfinishedDataDestroyerやTimesChannelDestroyer等による重要なデータクリーンアップ処理を実行するため、管理者による退会（triggered_by: 'admin'）の場合でも必ず実行する必要がある。
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 0
File: :0-0
Timestamp: 2025-07-23T21:11:21.826Z
Learning: fjordllc/bootcampプロジェクトの`app/models/work_notification_destroyer.rb`において、このクラスは`app/controllers/works_controller.rb`の`destroy`アクションから呼び出され、`before_action :set_my_work`でIDの妥当性チェックが事前に行われるため、payloadのworkオブジェクトは常に有効であることが保証されている。そのためエラーハンドリングは不要。
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:131-135
Timestamp: 2025-09-12T21:18:00.834Z
Learning: Rails アップグレードPRにおいて、product_review_not_completed メソッドの webhook URL 設定の shared フォールバック追加も、設定システム全体の変更として別PRで対応すべきである。
Learnt from: sharoa119
Repo: fjordllc/bootcamp PR: 9012
File: app/queries/grass_learning_time_query.rb:30-37
Timestamp: 2025-09-05T03:16:53.387Z
Learning: reports テーブルには既に (user_id, reported_on) の一意制約インデックス index_reports_on_user_id_and_reported_on が存在するため、学習時間集計クエリのパフォーマンス最適化には追加のインデックスは不要。
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/models/graduation_notifier.rb:23-28
Timestamp: 2025-09-12T21:16:47.639Z
Learning: Rails upgrade PRにおいて、configuration systemの変更やwebhook設定の改善提案も、アップグレードに直接関連しない場合は別PRで対応すべきである。PRのスコープ維持が重要。
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
db/migrate/20251103051313_backfill_comment_user_id_on_micro_reports.rb (1)
2-6: データマイグレーションではupdate_columnの使用を検討してください。
update!はバリデーションとコールバックをトリガーするため、データマイグレーション中に予期しない副作用や失敗が発生する可能性があります。また、report.user_idが nil または無効な場合のエラーハンドリングがありません。以下のように修正することを推奨します：
def up MicroReport.where(comment_user_id: nil).find_each do |report| - report.update!(comment_user_id: report.user_id) + next if report.user_id.blank? + report.update_column(:comment_user_id, report.user_id) end endこの変更により：
update_columnでバリデーション・コールバックをスキップし、データ移行を高速化user_idが nil の場合はスキップして、エラーを回避
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
app/controllers/users/micro_reports_controller.rb(3 hunks)db/migrate/20251103051313_backfill_comment_user_id_on_micro_reports.rb(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rb
⚙️ CodeRabbit configuration file
**/*.rb: # refactoring
- まずFat Controllerを避け、次にFat Modelを避ける。
- Serviceクラスの乱用を避ける。
- controller concernを作ろうとしたらPORO(Plain Old Ruby Object)やActiveRecordモデルでの実装で代替できないか検討する。
Rails Patterns
- ViewHelperにメソッドを実装する時にはまずDecoratorパターンを使うことを検討する。（active_decorator gemを導入しているのでそれを使う）
- 複雑なActiveRecordクエリがあり、再利用できそうな場合はQueryObjectパターンを検討する。（rails-patterns gemを導入しているのでそれのQuery機能を使う）
- Viewにpartialを作る場合はViewComponentを使うことを検討する。
- 複数のActiveRecordモデルを操作する１つの責務がある時や外部APIとやりとりする処理がある場合にはInteractorオブジェクトパターンを検討する。（interactor gemを導入しているのでそれを使う）
- 複数のInteractorを実行するような処理がある場合Organizerオブジェクトパターンを検討する。（interactor gemを導入しており、その中にOrganizerの機能があるので使う）
Files:
app/controllers/users/micro_reports_controller.rbdb/migrate/20251103051313_backfill_comment_user_id_on_micro_reports.rb
🧠 Learnings (9)
📓 Common learnings
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/models/graduation_notifier.rb:23-28
Timestamp: 2025-09-12T21:16:47.639Z
Learning: Rails upgrade PRにおいて、configuration systemの変更やwebhook設定の改善提案も、アップグレードに直接関連しない場合は別PRで対応すべきである。PRのスコープ維持が重要。
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:131-135
Timestamp: 2025-09-12T21:18:00.834Z
Learning: Rails アップグレードPRにおいて、product_review_not_completed メソッドの webhook URL 設定の shared フォールバック追加も、設定システム全体の変更として別PRで対応すべきである。
📚 Learning: 2025-07-23T20:31:13.856Z
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 8977
File: app/controllers/reports_controller.rb:63-63
Timestamp: 2025-07-23T20:31:13.856Z
Learning: fjordllc/bootcampプロジェクトの`app/controllers/reports_controller.rb`において、`create`と`update`アクションは両方とも`report.save_uniquely`を使用し、同じ`:report_save`イベントと`'report.save'`イベントを発行する。これは両方とも本質的に「レポートの保存」操作であり、作成と更新を区別する必要がないためである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-12T21:17:26.029Z
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:19-23
Timestamp: 2025-09-12T21:17:26.029Z
Learning: Rails アップグレードPRにおいて、config_for(:secrets) を使った webhook URL 設定の shared セクション未参照問題は、設定システム全体の変更として別PRで対応すべきである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-12T21:18:00.834Z
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:131-135
Timestamp: 2025-09-12T21:18:00.834Z
Learning: Rails アップグレードPRにおいて、product_review_not_completed メソッドの webhook URL 設定の shared フォールバック追加も、設定システム全体の変更として別PRで対応すべきである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-01T22:31:57.345Z
Learnt from: matuaya
Repo: fjordllc/bootcamp PR: 9108
File: app/models/after_user_retirement.rb:0-0
Timestamp: 2025-09-01T22:31:57.345Z
Learning: fjordllc/bootcampプロジェクトにおいて、`Newspaper.publish(:retirement_create, { user: user })`はUnfinishedDataDestroyer（未チェックProduct・WIP Report削除、career_pathリセット）とTimesChannelDestroyer（Discord分報チャンネル削除）による重要なデータクリーンアップ処理を実行するため、退会のトリガーが何であろうと（admin、hibernation、user）必ず実行する必要がある。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-01T22:31:57.345Z
Learnt from: matuaya
Repo: fjordllc/bootcamp PR: 9108
File: app/models/after_user_retirement.rb:0-0
Timestamp: 2025-09-01T22:31:57.345Z
Learning: fjordllc/bootcampプロジェクトにおいて、`Newspaper.publish(:retirement_create, { user: user })`は通知処理ではなく、UnfinishedDataDestroyerやTimesChannelDestroyer等による重要なデータクリーンアップ処理を実行するため、管理者による退会（triggered_by: 'admin'）の場合でも必ず実行する必要がある。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-07-23T21:11:21.826Z
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 0
File: :0-0
Timestamp: 2025-07-23T21:11:21.826Z
Learning: fjordllc/bootcampプロジェクトの`app/models/work_notification_destroyer.rb`において、このクラスは`app/controllers/works_controller.rb`の`destroy`アクションから呼び出され、`before_action :set_my_work`でIDの妥当性チェックが事前に行われるため、payloadのworkオブジェクトは常に有効であることが保証されている。そのためエラーハンドリングは不要。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-07-15T04:26:24.899Z
Learnt from: masyuko0222
Repo: fjordllc/bootcamp PR: 8934
File: app/controllers/test_feature_toggle_controller.rb:4-6
Timestamp: 2025-07-15T04:26:24.899Z
Learning: テスト用の一時的なコードで、すぐにリバートされる予定の場合、nil安全性などの防御的プログラミングの実装は不要とされることがある。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-07-23T21:11:21.826Z
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 0
File: :0-0
Timestamp: 2025-07-23T21:11:21.826Z
Learning: fjordllc/bootcampプロジェクトの`app/models/inquiry_notifier.rb`において、`NOTIFICATION_SENDER_NAME`で指定される管理者ユーザーは必ず存在することがシステムの前提条件として保証されているため、senderがnilになることは想定されておらず、エラーハンドリングは不要である。
Applied to files:
app/controllers/users/micro_reports_controller.rb
🧬 Code graph analysis (1)
app/controllers/users/micro_reports_controller.rb (1)
app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build_and_test
🔇 Additional comments (3)
app/controllers/users/micro_reports_controller.rb (3)
14-25: 他ユーザーの分報へのコメント投稿が正しく実装されています。
comment_user = current_userの設定により、コメント作成者が適切に記録され、Line 18の所有者チェック削除により、PRの目的である「他のユーザーの分報でもコメントを投稿できる」機能が正しく実装されています。
27-29: 認可チェックが適切に実装されています。過去のレビューで指摘されていたセキュリティ問題が修正され、
redirect_toによる早期リターンで不正なアクセスを適切にブロックしています。管理者またはコメント作成者のみが削除できるロジックも正確です。
47-54: スコープを使った認可パターンが適切に実装されています。管理者以外のユーザーは
authored_micro_reportsにスコープされるため、自分が作成したコメント以外にアクセスできません。Line 28の認可チェックと組み合わせることで多層防御となっており、セキュアな実装です。
ご指摘いただきありがとうございます
こちらの事象を解消し、テストも追加いたしました |
|
レビューいただきありがとうございました |
kutimiti1234
left a comment
kutimiti1234
left a comment
There was a problem hiding this comment.
ご対応ありがとうございます。前回指摘事項はすべて対応いただけていたかと思います。
細かい表記上の点についてだけコメントさせていただきます。
| end | ||
|
|
||
| def destroy | ||
| return redirect_to user_micro_reports_path(@user), alert: '権限がありません。' unless current_user.admin? || @micro_report.comment_user == current_user |
There was a problem hiding this comment.
この場合、unlessではなくif文で書いた方が脳みそにやさしいのかなと
if !current_user.admin? && @micro_report.comment_user != current_userThere was a problem hiding this comment.
おっしゃる通りで可読性が悪いので、unlessではなく、ifに変更しました
|
あと1点今回の修正範囲から外れてしまうのですが、destroy時にページの範囲外になってしまった場合にlatestへ遷移させるため、下記のメソッドで範囲外となったかの判定行っていると思います。 def page_out_of_range?(referer_path)
matched_page_number = referer_path.match(/page=(\d+)/)
page_number = matched_page_number ? matched_page_number[1] : FIRST_PAGE
MicroReport.page(page_number).out_of_range?
endここの MicroReport.page(page_number).out_of_range?について、私の認識があっていればある特定のユーザーの分報以外も含んでページの範囲外判定をしているのですが、こちら問題なかったでしょうか |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
app/controllers/users/micro_reports_controller.rb (1)
28-31: 条件式の可読性についての別の視点。kutimiti1234さんの提案に従って
ifで書かれていますが、ド・モルガンの法則により以下のようにunlessで書いた方がRuby的には自然かもしれません：unless current_user.admin? || @micro_report.comment_user == current_user redirect_to user_micro_reports_path(@user), alert: '権限がありません。' return end
!A && !Bは!(A || B)と等価なので、「管理者または作成者でない場合」という意図が明確になります。ただし、現在の実装も十分読みやすいため、お好みで判断してください。
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
app/controllers/users/micro_reports_controller.rb(4 hunks)app/models/user.rb(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- app/models/user.rb
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rb
⚙️ CodeRabbit configuration file
**/*.rb: # refactoring
- まずFat Controllerを避け、次にFat Modelを避ける。
- Serviceクラスの乱用を避ける。
- controller concernを作ろうとしたらPORO(Plain Old Ruby Object)やActiveRecordモデルでの実装で代替できないか検討する。
Rails Patterns
- ViewHelperにメソッドを実装する時にはまずDecoratorパターンを使うことを検討する。（active_decorator gemを導入しているのでそれを使う）
- 複雑なActiveRecordクエリがあり、再利用できそうな場合はQueryObjectパターンを検討する。（rails-patterns gemを導入しているのでそれのQuery機能を使う）
- Viewにpartialを作る場合はViewComponentを使うことを検討する。
- 複数のActiveRecordモデルを操作する１つの責務がある時や外部APIとやりとりする処理がある場合にはInteractorオブジェクトパターンを検討する。（interactor gemを導入しているのでそれを使う）
- 複数のInteractorを実行するような処理がある場合Organizerオブジェクトパターンを検討する。（interactor gemを導入しており、その中にOrganizerの機能があるので使う）
Files:
app/controllers/users/micro_reports_controller.rb
🧠 Learnings (17)
📓 Common learnings
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:131-135
Timestamp: 2025-09-12T21:18:00.834Z
Learning: Rails アップグレードPRにおいて、product_review_not_completed メソッドの webhook URL 設定の shared フォールバック追加も、設定システム全体の変更として別PRで対応すべきである。
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/models/graduation_notifier.rb:23-28
Timestamp: 2025-09-12T21:16:47.639Z
Learning: Rails upgrade PRにおいて、configuration systemの変更やwebhook設定の改善提案も、アップグレードに直接関連しない場合は別PRで対応すべきである。PRのスコープ維持が重要。
📚 Learning: 2025-07-23T20:31:13.856Z
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 8977
File: app/controllers/reports_controller.rb:63-63
Timestamp: 2025-07-23T20:31:13.856Z
Learning: fjordllc/bootcampプロジェクトの`app/controllers/reports_controller.rb`において、`create`と`update`アクションは両方とも`report.save_uniquely`を使用し、同じ`:report_save`イベントと`'report.save'`イベントを発行する。これは両方とも本質的に「レポートの保存」操作であり、作成と更新を区別する必要がないためである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-12T21:17:26.029Z
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:19-23
Timestamp: 2025-09-12T21:17:26.029Z
Learning: Rails アップグレードPRにおいて、config_for(:secrets) を使った webhook URL 設定の shared セクション未参照問題は、設定システム全体の変更として別PRで対応すべきである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-12T21:18:00.834Z
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:131-135
Timestamp: 2025-09-12T21:18:00.834Z
Learning: Rails アップグレードPRにおいて、product_review_not_completed メソッドの webhook URL 設定の shared フォールバック追加も、設定システム全体の変更として別PRで対応すべきである。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-01T22:31:57.345Z
Learnt from: matuaya
Repo: fjordllc/bootcamp PR: 9108
File: app/models/after_user_retirement.rb:0-0
Timestamp: 2025-09-01T22:31:57.345Z
Learning: fjordllc/bootcampプロジェクトにおいて、`Newspaper.publish(:retirement_create, { user: user })`はUnfinishedDataDestroyer（未チェックProduct・WIP Report削除、career_pathリセット）とTimesChannelDestroyer（Discord分報チャンネル削除）による重要なデータクリーンアップ処理を実行するため、退会のトリガーが何であろうと（admin、hibernation、user）必ず実行する必要がある。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-01T22:31:57.345Z
Learnt from: matuaya
Repo: fjordllc/bootcamp PR: 9108
File: app/models/after_user_retirement.rb:0-0
Timestamp: 2025-09-01T22:31:57.345Z
Learning: fjordllc/bootcampプロジェクトにおいて、`Newspaper.publish(:retirement_create, { user: user })`は通知処理ではなく、UnfinishedDataDestroyerやTimesChannelDestroyer等による重要なデータクリーンアップ処理を実行するため、管理者による退会（triggered_by: 'admin'）の場合でも必ず実行する必要がある。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-07-23T21:11:21.826Z
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 0
File: :0-0
Timestamp: 2025-07-23T21:11:21.826Z
Learning: fjordllc/bootcampプロジェクトの`app/models/work_notification_destroyer.rb`において、このクラスは`app/controllers/works_controller.rb`の`destroy`アクションから呼び出され、`before_action :set_my_work`でIDの妥当性チェックが事前に行われるため、payloadのworkオブジェクトは常に有効であることが保証されている。そのためエラーハンドリングは不要。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-07-15T04:26:24.899Z
Learnt from: masyuko0222
Repo: fjordllc/bootcamp PR: 8934
File: app/controllers/test_feature_toggle_controller.rb:4-6
Timestamp: 2025-07-15T04:26:24.899Z
Learning: テスト用の一時的なコードで、すぐにリバートされる予定の場合、nil安全性などの防御的プログラミングの実装は不要とされることがある。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-07-23T21:11:21.826Z
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 0
File: :0-0
Timestamp: 2025-07-23T21:11:21.826Z
Learning: fjordllc/bootcampプロジェクトの`app/models/inquiry_notifier.rb`において、`NOTIFICATION_SENDER_NAME`で指定される管理者ユーザーは必ず存在することがシステムの前提条件として保証されているため、senderがnilになることは想定されておらず、エラーハンドリングは不要である。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-05T03:16:53.387Z
Learnt from: sharoa119
Repo: fjordllc/bootcamp PR: 9012
File: app/queries/grass_learning_time_query.rb:30-37
Timestamp: 2025-09-05T03:16:53.387Z
Learning: reports テーブルには既に (user_id, reported_on) の一意制約インデックス index_reports_on_user_id_and_reported_on が存在するため、学習時間集計クエリのパフォーマンス最適化には追加のインデックスは不要。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-12T21:16:47.639Z
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/models/graduation_notifier.rb:23-28
Timestamp: 2025-09-12T21:16:47.639Z
Learning: Rails upgrade PRにおいて、configuration systemの変更やwebhook設定の改善提案も、アップグレードに直接関連しない場合は別PRで対応すべきである。PRのスコープ維持が重要。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-12T21:17:45.295Z
Learnt from: komagata
Repo: fjordllc/bootcamp PR: 9101
File: app/notifiers/discord_notifier.rb:52-56
Timestamp: 2025-09-12T21:17:45.295Z
Learning: Rails upgrade PRにおいて、configuration systemの改善提案（shared configuration fallback等）も、アップグレードに直接関連しない場合は別PRで対応すべきである。PRのスコープ維持が重要。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-09-02T19:01:08.804Z
Learnt from: matuaya
Repo: fjordllc/bootcamp PR: 9108
File: app/models/after_user_retirement.rb:43-45
Timestamp: 2025-09-02T19:01:08.804Z
Learning: fjordllc/bootcampプロジェクトの`app/models/card.rb`は、ActiveRecordモデルではなくStripe APIをラップしたカスタムクラスである。`Card.destroy_all(customer_id)`メソッドは、指定されたcustomer_idに関連付けられたカードのみを削除するカスタム実装で、ActiveRecordの`destroy_all`とは動作が異なり安全である。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-10-22T06:04:36.036Z
Learnt from: sjabcdefin
Repo: fjordllc/bootcamp PR: 9247
File: app/controllers/checks_controller.rb:0-0
Timestamp: 2025-10-22T06:04:36.036Z
Learning: ChecksController#createおよび#destroyでは、Checkの作成・削除とActiveSupport::Notifications.instrumentによるイベント発行(プラクティスのステータス更新)を同一トランザクション内で実行し、いずれかが失敗した場合は両方をロールバックする。これによりWebUI表示とDB状態の整合性を保証している。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-11-03T04:53:33.424Z
Learnt from: jun-kondo
Repo: fjordllc/bootcamp PR: 9202
File: config/initializers/active_support_notifications.rb:6-7
Timestamp: 2025-11-03T04:53:33.424Z
Learning: app/controllers/api/answers_controller.rb の destroy アクションにおいて、answer.destroy イベントは `if answer.type == 'CorrectAnswer'` 条件付きで発行される。通常の Answer 削除では未解決問題数に影響しないため、ベストアンサー (CorrectAnswer) 削除時のみ AnswerCacheDestroyer によるキャッシュクリアが必要。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-08-31T03:39:07.792Z
Learnt from: mousu-a
Repo: fjordllc/bootcamp PR: 8566
File: app/views/pair_works/_body.html.slim:85-85
Timestamp: 2025-08-31T03:39:07.792Z
Learning: app/views/pair_works/_body.html.slimテンプレートには2つの独立したif pair_work.solved?条件分岐があり、user変数は最初の分岐でのみ設定されるため、2番目の分岐での参照には注意が必要。
Applied to files:
app/controllers/users/micro_reports_controller.rb
📚 Learning: 2025-08-31T12:08:33.904Z
Learnt from: thmz337
Repo: fjordllc/bootcamp PR: 9103
File: app/views/generations/_user.html.slim:6-14
Timestamp: 2025-08-31T12:08:33.904Z
Learning: app/views/generations/_user.html.slimの非アクティブメッセージ表示では、退会・休会・非アクティブの3つの条件が独立して評価され、複数のメッセージが同時に表示される仕様になっている。これは意図的な設計である。
Applied to files:
app/controllers/users/micro_reports_controller.rb
🧬 Code graph analysis (1)
app/controllers/users/micro_reports_controller.rb (1)
app/components/users/micro_reports/micro_report_component.rb (1)
comment_user(10-12)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build_and_test
🔇 Additional comments (2)
app/controllers/users/micro_reports_controller.rb (2)
14-25: LGTM！他のユーザーも分報にコメントできるようになっています。
comment_user = current_userを設定し、以前のcurrent_user == @userチェックを削除することで、PRの目的である「他のユーザーの分報でもコメントを投稿できる」機能が正しく実装されています。
63-68: kutimiti1234さんの懸念が解決されています。Line 67 の実装を
@user.micro_reports.page(page_number).out_of_range?に変更したことで、特定ユーザーの分報のみを対象に範囲外判定を行うようになっています。以前のMicroReport.page(page_number).out_of_range?では全ユーザーの分報を対象に判定していた問題が修正されました。
ご指摘のように全ユーザーの分報 (MicroReport.all) を対象にしているので、「特定ユーザー（@user）」の分報だけを扱うように変更しました |
こちら分報コメント作成時にlatestに遷移するのが正しいので、修正しました |
|
|
Tip For best results, initiate chat on the files or code changes. @nakamu-kazu222 承知しました！ このような nitpick レベルの提案は、あくまで参考情報としてご提示しているものですので、チームやご自身の好みに応じて判断していただければと思います 👍 🧠 Learnings used |
belongs_to を明示的に :inverse_of で指定した
テストデータにcomment_userを追加 comment_userをデフォルトにセットした
undefined method `icon_title'を修正した test_form_not_found_in_other_user_microo_reports_pageのテストを通るようにした
また、test_form_not_found_in_other_user_microo_reports_pageは今回の実装では不要なテストなので削除した
authorize_micro_report!メソッドで、認可失敗時にリダイレクトまたはエラーを発生させるようにした test/models/micro_report_test.rbに、set_default_comment_userメソッドのUnitテストを追加した app/models/user.rbのhas_manyの定義を修正した test/components/users/micro_reports/micro_report_component_test.rbに管理者ユーザーのテストケースを追加した
test/components/users/micro_reports/micro_report_component_test.rbにコメントユーザーのアイコンと名前の表示を検証するアサーションをテストに追加した
admin以外のユーザーが他のユーザーの分報にコメントし、削除した時にエラーになったので解消した
destroy でしか実行されないので action 内に直接記述した
「ログインしていないと分報ページにアクセスできない」前提なので削除した
下記の手順で事象が発生した 1. kimura(adinではないユーザー)でログイン 2. kensyu(adinではないユーザー)の分報にコメントをする 3. 2のコメントを編集する 4. 新しくコメントをする 5. 2の編集したコメントが編集前のコメントに戻っている
既存レコードのコメントが削除されなくなるので、マイグレーションを追加し、コントローラーの記述をcoderabbitaiの参考のコードに修正した
update!の記述を使用しない方がいいと推奨されたため別の記述をした
既存のマイグレーションの内容を変更しても再実行されないので、新しいマイグレーションを追加した また、修正したマイグレーションは元に戻した
特定ユーザーの分報ページで削除後のリダイレクト先が誤る可能性があるので、特定ユーザーの分報ページ範囲に基づいた正しいリダイレクトにした
コントローラーに定義しているPAGER_NUMBERを25→5などに変更すると、正しく遷移されない。 Model ではデフォルト値を持ち、Controller 側で上書き可能にするようにした
nakamu-kazu222
force-pushed
the
feature/micro-reports-others-user-comments
branch
from
4439e77 to
51cec70
Compare
|
@komagata さん お疲れ様です |
|
@komagata さん ご確認いただきありがとうございます。 |
|
@nakamu-kazu222 ありがとうございます。 |
4 participants
Issue
概要
自分の分報は自分しか書き込めないが、他人も書き込めるようにした
また、分報のコメントを編集・削除できるのは管理者(adminユーザー)またはコメントを書いた本人のみとした
変更確認方法
1. 環境構築
feature/micro-reports-others-user-commentsをローカルに取り込むrails db:resetを実行するbin/setupを実行するforeman start -f Procfile.devを実行するkomagataユーザーでログインする2. 他のユーザーの分報でもコメントを投稿できるかの確認
kimuraユーザーのマイプロフィールから分報ページ(/users/459775584/micro_reports?page=1#latest-micro-report)を開くkimuraユーザーでログインするkimuraユーザーのマイプロフィールから分報ページ(/users/459775584/micro_reports?page=1#latest-micro-report)を開くkimuraユーザーのみ「内容修正」、「削除する」ボタンが表示されていることを確認する3. 他のユーザーの分報でもコメントを編集、削除できるかの確認
kimuraユーザーでログインするkensyuユーザーのマイプロフィールから分報ページ(/users/301971253/micro_reports?page=1)を開くScreenshot
変更前
分報のオーナーのみコメントできた
変更後
分報のオーナー以外のユーザーがコメントを投稿できる
Summary by CodeRabbit
改善
新機能
テスト
✏️ Tip: You can customize this high-level summary in your review settings.