Conversation
|
このPRによるapi.jsonの差分 差分はこちら--- base
+++ head
@@ -1210,12 +1210,6 @@
"password": {
"type": "string",
"minLength": 1
- },
- "setupPassword": {
- "type": [
- "string",
- "null"
- ]
}
},
"required": [
@@ -87640,14 +87634,6 @@
},
"maxFileSize": {
"type": "number"
- },
- "federation": {
- "type": "string",
- "enum": [
- "all",
- "specified",
- "none"
- ]
}
},
"required": [
@@ -87708,8 +87694,7 @@
"policies",
"pointName",
"noteSearchableScope",
- "maxFileSize",
- "federation"
+ "maxFileSize"
]
},
"MetaDetailedOnly": { |
|
Thank you for sending us a great Pull Request! 👍 example: pnpm run build-misskey-js-with-types |
|
いつの話かわからんね |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
Walkthrough複数のバックエンド設定およびサービスにわたる変更：setupPasswordフィールドを削除し、カスタム絵文字およびユーザー登録用のウェブフックペイロード型を追加し、フェデレーション関連チェックを無効化し、InboxRuleの型をIActivityに変更し、メタデータスキーマからフェデレーションフィールドを削除し、各種フォーマッティング調整を実施。 Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~40 minutes 詳細確認が必要な項目：
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings, 1 inconclusive)
✨ 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 |
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 (2)
packages/backend/src/server/api/endpoints/ap/show.ts (1)
38-42: 未使用のエラー定義が残っています。
federationNotAllowedエラー定義が存在しますが、主要なチェック（144-147行目）がコメントアウトされているため、このエラーは現在throw されません。ただし、175行目のエラーハンドラーでは別のエラーID（'09d79f9e-64f1-4316-9cfa-e75c4d091574'）で同様のエラーがthrowされる可能性があります。フェデレーションチェックを再実装する予定がない場合は、このエラー定義を削除してください。再実装する予定がある場合は、Issueで追跡することをお勧めします。
packages/frontend/src/components/MkLaunchPad.vue (1)
110-124: ゲーミング背景アニメーションが::beforeオーバーレイで隠れる問題を解決してください検証結果、ゲーミングホバー効果と
::beforeオーバーレイの間に実際の視覚的競合があります。ホバー時に
.gamingDark:hover（または.gamingLight:hover）と一般的な:hoverセレクタの両方がマッチします：
- ゲーミング効果 (lines 110-124):
.itemに gradient アニメーションを設定- 一般的なホバー (line 156-162):
&::before { opacity: 1 }でオーバーレイを表示その結果、背景に設定された gradient アニメーションが、その上に表示される不透明な
::beforeオーバーレイによって完全に隠れてしまいます。ゲーミングモード時には
::beforeの表示を抑制するか、あるいはオーバーレイの透明度を調整して、ゲーミングアニメーションが見えるようにしてください。例えば、.gamingDark:hover ~::beforeや.gamingLight:hover ~ ::beforeに対してopacity: 0 !importantを設定するか、オーバーレイの背景を透明または半透明にする必要があります。
🧹 Nitpick comments (5)
packages/backend/src/queue/types.ts (1)
117-118: フォーマットの一貫性を保つことを検討してください。このファイル内の他のすべての型定義（
DeliverJobData、InboxJobData、DbJobDataWithUserなど）は、閉じ括弧を別の行に配置する複数行形式を使用していますが、ScheduleNotePostJobDataのみが1行形式になっています。可読性とコードの一貫性のため、以下のように他の型定義と同じ形式に戻すことをお勧めします：
export type ScheduleNotePostJobData = { - scheduledNoteId: MiNote['id']; -}; + scheduledNoteId: MiNote['id']; +};packages/frontend/src/components/MkLaunchPad.vue (1)
156-163: CSS変数の命名規則とアクセシビリティを確認してください
- CSS変数の一貫性: Line 139では
var(--MI_THEME-accentedBg)（アンダースコア）を使用していますが、Line 158ではvar(--MI_THEME-accent)を使用しています。CSS変数の命名規則が一貫しているか確認してください。- キーボードナビゲーション:
:focus状態が追加されたのは良いことですが、キーボードフォーカスの視認性を確保するために、outlineまたは明確なフォーカスインジケーターの追加を検討してください（特にゲーミング効果により背景が変化する場合）。フォーカスインジケーターの追加を検討してください：
&:hover, &.active, &:focus { text-decoration: none; color: var(--MI_THEME-accent); &::before { opacity: 1; } } + + &:focus-visible { + outline: 2px solid var(--MI_THEME-accent); + outline-offset: 2px; + }packages/backend/src/server/api/SignupApiService.ts (1)
126-133: Webhook エンキューのエラーハンドリングを確認してください。
forEachループ内でenqueueSystemWebhookを呼び出していますが、Promise が await されていません。これは意図的な "fire and forget" パターンかもしれませんが、Webhook の送信エラーが発生した場合、それが無視される可能性があります。エラーハンドリングが必要な場合は、
Promise.allSettledの使用を検討してください。もしエラーハンドリングが必要な場合、以下のような実装を検討してください：
- activeSystemWebhooksWithUserRegistered.forEach(it => this.systemWebhookService.enqueueSystemWebhook( - 'userRegistered', - { - username, - email: emailAddress ?? null, - host, - }, - )); + await Promise.allSettled( + activeSystemWebhooksWithUserRegistered.map(it => + this.systemWebhookService.enqueueSystemWebhook( + 'userRegistered', + { + username, + email: emailAddress ?? null, + host, + }, + ) + ) + );packages/backend/src/core/CustomEmojiService.ts (2)
110-110: Nullish coalescing 演算子への変更が適切です。
me ?? nullは元の三項演算子よりも簡潔で、null/undefined の明示的なチェックを行うため、より適切です。
108-111: Webhook エンキューのエラーハンドリングを確認してください。SignupApiService と同様に、
forEachループ内で非同期のenqueueSystemWebhookを呼び出していますが、Promise が await されていません。エラーハンドリングが必要な場合は、Promise.allSettledの使用を検討してください。
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (24)
packages/backend/src/config.ts(0 hunks)packages/backend/src/core/CustomEmojiService.ts(2 hunks)packages/backend/src/core/InboxRuleService.ts(3 hunks)packages/backend/src/core/SystemWebhookService.ts(2 hunks)packages/backend/src/core/UtilityService.ts(2 hunks)packages/backend/src/core/WebhookTestService.ts(4 hunks)packages/backend/src/core/activitypub/ApInboxService.ts(1 hunks)packages/backend/src/core/entities/MetaEntityService.ts(1 hunks)packages/backend/src/core/entities/UserEntityService.ts(1 hunks)packages/backend/src/misc/json-schema.ts(1 hunks)packages/backend/src/models/InboxRule.ts(2 hunks)packages/backend/src/models/json-schema/meta.ts(1 hunks)packages/backend/src/queue/processors/SystemWebhookDeliverProcessorService.ts(1 hunks)packages/backend/src/queue/types.ts(1 hunks)packages/backend/src/server/ActivityPubServerService.ts(1 hunks)packages/backend/src/server/FileServerService.ts(1 hunks)packages/backend/src/server/api/SignupApiService.ts(1 hunks)packages/backend/src/server/api/endpoint-list.ts(1 hunks)packages/backend/src/server/api/endpoints/admin/accounts/create.ts(1 hunks)packages/backend/src/server/api/endpoints/ap/show.ts(2 hunks)packages/backend/src/server/web/ClientServerService.ts(8 hunks)packages/frontend/src/components/MkLaunchPad.vue(2 hunks)packages/frontend/src/pages/welcome.setup.vue(0 hunks)packages/frontend/src/ui/_common_/navbar.vue(0 hunks)
💤 Files with no reviewable changes (3)
- packages/frontend/src/pages/welcome.setup.vue
- packages/frontend/src/ui/common/navbar.vue
- packages/backend/src/config.ts
🔇 Additional comments (31)
packages/backend/src/server/ActivityPubServerService.ts (2)
754-754: フォーマット修正のみLine 754でセミコロン前のスペースが削除されています。これは純粋なスタイル修正で、動作に影響ありません。
1-790: PR説明が不完全ですPRのタイトルは「テストの修正」ですが、実装内容はバックエンド設定・サービス修正であり、説明が欠落しています。PRの
What、Why、Additional infoセクションが空のままです。また、チェックリスト項目がすべてチェック済みになっていません。次回のPR作成時には、変更内容と変更理由を明確に記載することをお勧めします。
packages/backend/src/server/FileServerService.ts (1)
521-523: ホワイトスペース正規化は適切です。セミコロン前の余分なスペースの削除は、TypeScript標準ガイドラインに従うものであり、正しいフォーマッティングです。戻り値型の機能的な内容に変更はなく、型定義の正確性も影響を受けません。
packages/backend/src/server/api/endpoint-list.ts (1)
418-418: 実装ファイルの存在確認完了 - 懸念事項なしLine 418の
notes/home-local-timelineエンドポイントの実装ファイルが確認されました。エクスポート構文は他のエンドポイントと一貫しており、正しく統合されています。packages/backend/src/server/api/endpoints/ap/show.ts (1)
144-147: フェデレーションチェック無効化のセキュリティリスク評価スクリプト実行結果から以下が判明しました：
isFederationAllowedUriメソッドの実装全体がpackages/backend/src/core/UtilityService.ts（135-139行目）でコメントアウトされている- 呼び出し元の
show.ts（145行目）でもコメントアウトされている- 両箇所に同じTODO「機能するように」が付与されている
これは偶発的なバグではなく、意図的な機能無効化と見受けられます。ただし、以下の点が懸念されます：
- 149行目の
blockedHostsチェックのみでは、フェデレーション許可ルールの完全な検証が行われていない可能性がある- 149行目のチェックはブロック対象ホストをチェックしていますが、許可すべきホストの検証は行われていない
- PRの説明に無効化の理由・影響がない
- TODOにタイムラインや対応Issueが記録されていない
対応が必要な項目：
- この無効化が一時的か恒久的かを明確にする
- 対応するGitHub Issueを作成し、TODOにIssue番号を記載する
- ブロックホストチェックのみで十分か検証する
- 本番環境へのデプロイ前にこの変更の影響を再検証する
packages/backend/src/core/WebhookTestService.ts (4)
136-138: ノート編集履歴フィールドの追加は妥当です。検証結果：
MiNote型定義（packages/backend/src/models/Note.ts）にこれらのフィールドが含まれていることを確認しました。初期化値も型定義と一致しており、すべて正しく実装されています。
updatedAt: null→Date | null✓updatedAtHistory: []→Date[] | null✓noteEditHistory: []→string[]✓
93-93: ダミーユーザーのgetPointsフィールド追加は正確です。検証結果：
getPointsフィールドはUserモデル（packages/backend/src/models/User.ts行31）でnumber型として定義されており、デフォルト値0の設定は適切です。フィールドはJSON スキーマおよび複数のエンドポイントで活発に使用されています。
35-36: アビューズレポートのテストデータが型定義と一致することを確認しました。
MiAbuseUserReport型定義でnotes（any[]）とnoteIds（string[] | null）フィールドが正しく定義されており、WebhookTestService.tsの行35-36で追加されたテストデータの初期化は適切です。変更内容は問題ありません。
478-478: レビューコメントは誤りです。修正の必要はありません。2つのswitch文は異なる型を扱い、カバレッジが異なります：
- 行395（UserWebhook）:
webhookEventTypesの全8値がswitch文でカバーされているため、TypeScriptはparams.typeを自動的にnever型として推論でき、キャスト不要- 行478（SystemWebhook）:
systemWebhookEventTypesの8値のうち5値のみカバー（customEmojiRequest、customEmojiRequestResolved、userRegistered未処理）のため、TypeScriptはnever型を推論できず、as neverキャストが必要
as neverキャストは意図的で適切です。未実装の型があることを明示的に示しています。Likely an incorrect or invalid review comment.
packages/backend/src/core/entities/UserEntityService.ts (1)
494-494: フォーマットの改善を確認しました。
??演算子の前にスペースを追加することで、可読性が向上しています。機能的な変更はありません。packages/backend/src/misc/json-schema.ts (1)
36-36: インポート文のフォーマットを確認しました。カンマの後にスペースを追加することで、一貫性が向上しています。
packages/backend/src/core/UtilityService.ts (2)
12-12: 依存性注入の追加を確認しました。
MiMetaの依存性注入が追加されましたが、現在コメントアウトされている連合機能メソッド（Lines 124-139）でのみ使用される予定です。Also applies to: 19-21
124-139: レビューコメントは不正確です - 実際には実行時エラーは発生しません。検証の結果、
isFederationAllowedUriとisFederationAllowedHostへの呼び出しはコードベース内に存在しません。唯一の呼び出し箇所はap/show.tsの145行目にありますが、この呼び出しもまた同じTODOマーカーとともにコメントアウトされています。メソッドの定義と呼び出し側が両方ともコメント化されているため、実行時エラーは発生しません。これは意図的な機能の一時的な無効化であり、コードは一貫した状態にあります。
Likely an incorrect or invalid review comment.
packages/backend/src/core/InboxRuleService.ts (2)
9-10: 型の改善を確認しました。
IObjectからIActivityへの変更により、より具体的な型付けが実現されています。これはコードの型安全性を向上させる良い変更です。Also applies to: 38-38
108-131: 型ガードの追加により堅牢性が向上しました。各ケースで
activity.objectが文字列かどうかをチェックすることで、ランタイムエラーを防いでいます。また、オプショナルチェーンを使用した安全なプロパティアクセスも実装されています。改善点：
- Line 108: 文字列の
activity.objectを早期リターンで除外- Line 110:
Array.isArrayで配列チェック- Line 118:
attachment?.lengthでオプショナルチェーン使用- Line 130:
typeofチェックで型の安全性を確保これらの防御的プログラミング手法により、コードの信頼性が向上しています。
packages/backend/src/models/InboxRule.ts (2)
155-176: 型定義のフォーマット統一を確認しました。以下の一貫性の改善が行われています：
typeフィールドのコロン前のスペースを削除（Lines 155, 160, 165, 170, 175）- 型定義の終わりに統一して
;を使用（Lines 157, 162, 167, 172, 176）これらの変更により、TypeScriptの慣例に従った一貫性のあるコードスタイルになっています。
210-210: 型定義のフォーマット統一を確認しました。
InboxRuleAction型の終わりに;が追加され、他の型定義と一貫性が保たれています。packages/backend/src/core/entities/MetaEntityService.ts (1)
147-147: TODO コメントを具体的な issue番号で追跡可能にするか、コメントアウトされたコードを削除してください。検証結果より、
federationフィールドのコメントアウトはユーザー向けメタレスポンスのみに限定されていることが判明しました。ただし、以下の点に留意してください：
- federation 機能は完全に無効化されていない：FederationChart、federation API エンドポイント、charts/federation などは依然として機能しています
- 不一貫性：admin/meta エンドポイント（packages/backend/src/server/api/endpoints/admin/meta.ts:652-656）には
federationフィールドが存在したままです- 未追跡 TODO：同じパターンの「TODO 機能するように」コメントが複数箇所（UtilityService.ts, ap/show.ts）に存在し、issue 番号による追跡がされていません
対応方法：
- 再実装予定がある場合、GitHub issue 番号を含む具体的な TODO コメント（例：
// TODO #12345: federation...）に変更してください- または、この変更が永続的である場合、コメントアウトされたコードと TODO コメント自体を削除してください
- admin/meta との一貫性を確認し、必要に応じて整合性を取ってください
packages/backend/src/server/api/SignupApiService.ts (1)
10-10: 型のみのインポートへの変更が適切です。リポジトリとモデルの型を
typeキーワードでインポートすることで、TypeScript のベストプラクティスに従っており、ランタイムバンドルサイズの削減に貢献しています。packages/backend/src/queue/processors/SystemWebhookDeliverProcessorService.ts (1)
39-46: LGTM！フォーマット変更のみで、ロジックに影響はありません。
packages/backend/src/core/CustomEmojiService.ts (1)
205-218: LGTM！メソッドシグネチャのフォーマット変更のみで、機能に影響はありません。
packages/backend/src/core/SystemWebhookService.ts (2)
8-8: 新しい型定義が適切に追加されています。
CustomEmojiRequestPayload型の追加により、カスタム絵文字リクエスト関連のWebhookペイロードの型安全性が向上しています。Also applies to: 38-41
47-54: Webhook ペイロード型のマッピングが適切です。
SystemWebhookPayload型が拡張され、新しいイベントタイプに対応しています。条件付き型を使用した型安全なアプローチで、各イベントタイプに正しいペイロード構造が割り当てられています。packages/backend/src/server/web/ClientServerService.ts (8)
47-47: LGTM: インポート文のフォーマット修正型インポートリストのカンマ後のスペースが正しく修正されています。
638-666: LGTM: フォーマット改善コードのインデントと整形が改善されていますが、ロジックは変更されていません。
704-733: LGTM: ノートルートハンドラのリファクタリングnot-foundケースの処理が
renderBase(reply)で統一され、コードが簡潔になりました。クエリレベルでvisibility: In(['public', 'home'])によるフィルタリングが行われているため、非公開ノートは取得されず、この簡略化は適切です。
752-773: LGTM: ページルートハンドラの統一的なリファクタリングノートハンドラと同様に、not-foundケースの処理が統一されています。可視性チェックは条件分岐内で行われており、適切な実装です。
783-800: LGTM: Flashルートハンドラの統一的なリファクタリング他のルートハンドラと同様の統一的なパターンが適用されており、コードの一貫性が向上しています。
810-830: LGTM: Clipルートハンドラの統一的なリファクタリング
clip.isPublicチェックを含む統一的なパターンが適用されており、非公開クリップに対する適切な処理が維持されています。
840-857: LGTM: ギャラリー投稿ルートハンドラの統一的なリファクタリング全てのルートハンドラで統一的なearly-returnパターンが適用されており、コードの保守性と可読性が向上しています。
555-564: レビューコメントは無効です - requireSigninToViewContents機能は既に削除されていますこのレビューコメントの懸念は根拠がありません。
requireSigninToViewContentsフィールドは既にコミット9ff47df215で完全に削除されており、User エンティティに存在しません。したがって、getFeed関数から「フィルタを削除した」わけではなく、そもそも機能自体がシステムから削除されています。Likely an incorrect or invalid review comment.
| } else if (getApType(object) === 'Note' || getApType(object) === 'Question') { | ||
| await this.updateNote(resolver, actor, object, false, activity); | ||
| return 'ok: Note updated'; | ||
| } else { | ||
| return `skip: Unknown type: ${getApType(object)}`; | ||
| } | ||
| } /*else if (getApType(object) === 'Question') { | ||
| await this.apQuestionService.updateQuestion(object, actor, resolver).catch(err => console.error(err)); | ||
| return 'ok: Question updated'; | ||
| }*/ |
There was a problem hiding this comment.
🧩 Analysis chain
Question型の処理統合を確認してください。
Question型の更新処理がNote更新パスに統合されました。コメントアウトされたapQuestionService.updateQuestionの呼び出しが残っています。
確認事項：
updateNoteメソッドがQuestion型を正しく処理できることを確認してくださいapQuestionService.updateQuestionに固有のロジックがあった場合、それが失われていないか検証してください- コメントアウトされたコード（Lines 827-830）は削除するか、適切なTODOコメントで追跡してください
以下のスクリプトでQuestionの処理を確認してください：
🏁 Script executed:
#!/bin/bash
# Description: updateNoteメソッドがQuestion型を処理できるか確認
# updateNoteメソッドの実装を確認
echo "=== updateNote implementation ==="
ast-grep --pattern $'updateNote($$$) {
$$$
}'
# apQuestionService.updateQuestionの使用箇所を確認
echo "=== apQuestionService.updateQuestion usage ==="
rg -n "apQuestionService\.updateQuestion" --type=ts -C3Length of output: 765
より詳細な情報が必要です。以下の検証を進めます：
🏁 Script executed:
#!/bin/bash
# Find updateNote method implementation
echo "=== Searching for updateNote method ==="
rg -n "updateNote\s*\(" --type=ts -B2 -A10 packages/backend/src/core/activitypub/ApInboxService.ts
# Check if updateNote has type guards for Question
echo "=== Check for Question handling in updateNote ==="
rg -n "Question" --type=ts packages/backend/src/core/activitypub/ApInboxService.tsLength of output: 1977
🏁 Script executed:
#!/bin/bash
# Find apNoteService.updateNote method to see if it handles Question
echo "=== Finding apNoteService.updateNote method ==="
fd -n "ApNoteService" --type=f | head -5
# Check apNoteService.updateNote implementation
echo "=== Checking ApNoteService.updateNote implementation ==="
rg -n "updateNote\s*\(" --type=ts -A20 -g "*ApNoteService*"
# Compare with apQuestionService.updateQuestion
echo "=== Checking ApQuestionService.updateQuestion ==="
fd -n "ApQuestionService" --type=f | head -5Length of output: 2666
🏁 Script executed:
#!/bin/bash
# Find ApQuestionService file
echo "=== Finding ApQuestionService file ==="
find packages/backend/src -name "*ApQuestionService*" -type f
# Find updateQuestion method in ApQuestionService
echo "=== Checking ApQuestionService.updateQuestion ==="
rg -n "updateQuestion\s*\(" --type=ts -A20 packages/backend/src/core/activitypub/models/
# Check what type apQuestionService.updateQuestion expects
echo "=== Check updateQuestion signature and implementation ==="
rg -n "class ApQuestionService" --type=ts -A50 packages/backend/src/core/activitypub/models/Length of output: 7667
🏁 Script executed:
#!/bin/bash
# Get more context from updateQuestion to confirm poll update logic
echo "=== ApQuestionService.updateQuestion full implementation ==="
rg -n "updateQuestion\s*\(" --type=ts -A80 packages/backend/src/core/activitypub/models/ApQuestionService.ts | head -100
# Check if apNoteService handles polls
echo "=== Checking if apNoteService handles polls ==="
rg -n "poll" --type=ts packages/backend/src/core/activitypub/models/ApNoteService.ts | head -20Length of output: 3549
Question型更新時のポーラ投票数同期が失われています。
ApQuestionService.updateQuestionはQuestion型のUpdate活動に対してポーラの投票数カウントを同期する重要な処理を行います。これをupdateNoteパスにマージすることで、この機能が失われています。
問題点：
apQuestionService.updateQuestionは既存のポーラの投票数を同期（lines 114-122）updateNoteはノートコンテンツ更新のみで、ポーラ投票数の同期を行わない- Question型のUpdate活動でポーラの投票数が更新されなくなる
修正方法：
- コメントアウトされたQuestion処理を復活させ、
apQuestionService.updateQuestionを呼び出してください - または、
updateNote内でQuestion型を検出して、apQuestionService.updateQuestionを別途呼び出すロジックを追加してください - コメントアウトされたコード（lines 827-830）は削除するか、TDOコメントで追跡してください
🤖 Prompt for AI Agents
In packages/backend/src/core/activitypub/ApInboxService.ts around lines 822 to
830, the Update handling merged Question into the updateNote path causing
apQuestionService.updateQuestion (which syncs poll/vote counts) to be skipped;
restore explicit Question handling by detecting getApType(object) === 'Question'
and calling await this.apQuestionService.updateQuestion(object, actor, resolver)
(propagate or log errors consistently and return an appropriate 'ok: Question
updated' message), or alternatively modify updateNote to detect Question and
call apQuestionService.updateQuestion there; also remove or convert the
commented-out block (lines 827-830) into either the active code or a TODO and
ensure the response strings remain consistent.
| // federation: { | ||
| // type: 'string', | ||
| // enum: ['all', 'specified', 'none'], | ||
| // optional: false, nullable: false, | ||
| // }, |
There was a problem hiding this comment.
🧩 Analysis chain
API破壊的変更：連合機能フィールドの削除を確認してください。
federation フィールドをスキーマからコメントアウトすることで、公開APIから削除されています。これは既存のクライアントに影響を与える可能性があります。
懸念事項：
- この変更により、
MetaLiteスキーマを使用しているクライアントがfederationフィールドにアクセスできなくなります - コメントアウトされたコードは、完全に削除するか、適切なissue番号でTODOとして追跡する必要があります
- 連合機能を再度有効にする予定がある場合、マイグレーション戦略を検討してください
この変更の影響範囲を確認するため、以下のスクリプトを実行してください：
🏁 Script executed:
#!/bin/bash
# Description: MetaLiteスキーマとfederationフィールドの使用箇所を検索
# MetaLiteスキーマの参照を検索
echo "=== MetaLite schema references ==="
rg -n "MetaLite" --type=ts -C3
# federationフィールドへのアクセスを検索
echo "=== federation field accesses ==="
rg -n "\.federation" --type=ts -C3Length of output: 15819
🏁 Script executed:
#!/bin/bash
# Verify where instance variable gets populated in frontend
# Check the context around federation usage in common.ts
echo "=== common.ts federation usage context ==="
sed -n '55,75p' packages/frontend/src/ui/_common_/common.ts
# Check the context around federation usage in please-login.ts
echo -e "\n=== please-login.ts federation usage context ==="
sed -n '50,65p' packages/frontend/src/scripts/please-login.ts
# Search for instance variable definition/assignment
echo -e "\n=== Where does 'instance' come from in common.ts? ==="
rg -n "import.*instance|const.*instance.*=|let.*instance.*=" packages/frontend/src/ui/_common_/common.ts -B2 -A2
# Search for instance initialization in frontend
echo -e "\n=== Instance store/variable in frontend ==="
rg -n "misskeyInstance|instance.*=" packages/frontend/src/ --type=ts -l | head -10Length of output: 1793
🏁 Script executed:
#!/bin/bash
# Verify where instance comes from and how it's populated
# Check import and initialization in common.ts
echo "=== common.ts imports and initialization ==="
head -70 packages/frontend/src/ui/_common_/common.ts | grep -A5 -B5 "instance"
# Check please-login.ts imports
echo -e "\n=== please-login.ts instance usage ==="
head -65 packages/frontend/src/scripts/please-login.ts | grep -A5 -B5 "instance\|federation"Length of output: 1565
🏁 Script executed:
#!/bin/bash
# Check how instance is initialized in frontend
echo "=== packages/frontend/src/instance.ts content ==="
cat packages/frontend/src/instance.tsLength of output: 2495
連合フィールド削除により、複数のフロントエンドファイルが破損します。
検証結果：スキーマからの federation フィールド削除がフロントエンド機能を直接破壊することを確認しました。
フロントエンドは /api/meta 端点から MetaDetailed 型として instance を取得し、以下の場所で federation フィールドにアクセスします：
- packages/frontend/src/ui/common/common.ts:66 —
if (instance.federation !== 'none')で連合メニュー表示を制御 - packages/frontend/src/scripts/please-login.ts:58 —
if (instance.federation !== 'none' || ...)でリモートログインオプション設定
バックエンド側でスキーマ（meta.ts:368-372）と MetaEntityService（line:147）から federation をコメントアウトすると、API レスポンスにこのフィールドが含まれなくなり、上記のフロントエンドコードで undefined 参照エラーが発生します。
修正必須：
federationフィールドを復元するか- フロントエンド両ファイルの federation アクセスをコンポーネント削除・リファクタリング含めて対応するか
- どちらか一つを選択して進める
🤖 Prompt for AI Agents
In packages/backend/src/models/json-schema/meta.ts around lines 368-372 the
federation field was removed causing /api/meta to omit federation and break
frontend consumers; restore the federation schema entry with type 'string', enum
['all','specified','none'], and non-nullable/required flags (matching previous
semantics), then ensure MetaEntityService (around line 147) includes federation
in the emitted MetaDetailed object; after restoring, run backend tests and
verify packages/frontend/src/ui/_common_/common.ts:66 and
packages/frontend/src/scripts/please-login.ts:58 receive instance.federation (or
update those files if you intentionally choose to remove the feature instead of
restoring the field).
| if ((realUsers && !me?.isRoot) || token !== null) { | ||
| // 初回セットアップではなく、管理者でない場合 or 外部トークンを使用している場合 | ||
| throw new ApiError(meta.errors.accessDenied); | ||
| } |
There was a problem hiding this comment.
初回セットアップが完全に無防備になります
ここで setupPassword による初期セットアップ認証が消えたため、realUsers が存在しない状態 (実稼働直後など) では、未認証の第三者が token=null で POST するだけで最初の管理者アカウントを発行できてしまいます。旧ロジックが防いでいた遠隔初期化攻撃が復活してしまうので、初回セットアップ時にも共有シークレットや別の強固な認証手段を再度要求するよう巻き戻し／再設計してください。
🤖 Prompt for AI Agents
In packages/backend/src/server/api/endpoints/admin/accounts/create.ts around
lines 75 to 78, the current check allows account creation when realUsers is
falsy and token is null, enabling unauthenticated remote initialization;
restore/reintroduce the initial-setup authentication by requiring the setup
shared secret (e.g., setupPassword) or another strong auth method for the first
admin creation: if realUsers is falsy (initial setup) validate the provided
setupPassword/shared-secret (or a configured setup token) before allowing
creation, otherwise keep the existing checks that require me?.isRoot or a valid
token; update the condition and error path to reject requests that do not
present the setup secret during initial setup and keep logs/audit for failed
attempts.
| &::before { | ||
| content: ""; | ||
| display: block; | ||
| height: 100%; | ||
| aspect-ratio: 1; | ||
| margin: auto; | ||
| position: absolute; | ||
| top: 0; | ||
| left: 0; | ||
| right: 0; | ||
| bottom: 0; | ||
| border-radius: 16px; | ||
| opacity: 0; | ||
| background: var(--MI_THEME-accentedBg); | ||
| text-decoration: none; | ||
| transition: opacity 0.2s ease; | ||
| } |
There was a problem hiding this comment.
オーバーレイのレイアウトとz-indexの問題を確認してください
以下の潜在的な問題があります：
- サイズの不一致:
height: 100%とaspect-ratio: 1の組み合わせにより、オーバーレイは正方形（100px × 100px）になりますが、親要素.itemの幅はgrid-template-columns: repeat(auto-fill, minmax(100px, 1fr))により100pxより大きくなる可能性があります。これにより、オーバーレイがボタン全体を覆わない場合があります。 - z-indexの欠如:
::before擬似要素にz-indexが指定されていないため、アイコンやテキストの上に表示される可能性があります。視認性を確保するためにz-index: -1またはz-index: 0を追加し、アイコンとテキストにはposition: relative; z-index: 1を設定することを検討してください。 - Gaming効果との競合: Lines 110-124 の
.gamingDark:hoverと.gamingLight:hoverは要素のbackgroundを直接設定しており、この新しいオーバーレイアプローチと競合する可能性があります。
以下の修正を適用してください：
&::before {
content: "";
display: block;
- height: 100%;
- aspect-ratio: 1;
+ width: 100%;
+ height: 100%;
margin: auto;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;
border-radius: 16px;
opacity: 0;
background: var(--MI_THEME-accentedBg);
transition: opacity 0.2s ease;
+ z-index: 0;
}
> .icon {
+ position: relative;
+ z-index: 1;
opacity: 0.7;
font-size: 24px;
height: 24px;
}
> .text {
+ position: relative;
+ z-index: 1;
margin-top: 12px;
font-size: 0.8em;
line-height: 1.5em;Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
packages/frontend/src/components/MkLaunchPad.vue around lines 126-141: the
::before overlay uses height:100% with aspect-ratio:1 which can make it too
small for grid items, lacks a z-index (so it may sit above icon/text), and may
conflict with existing .gamingDark:hover/.gamingLight:hover background rules;
fix by changing the pseudo-element to fill the parent (use width:100%;
height:100%; remove aspect-ratio), add z-index:-1 on ::before and ensure the
icon/text elements have position:relative and z-index:1 so they stay above the
overlay, switch hover effects to toggle the ::before opacity (or adjust hover
rules to target ::before) so background hover and overlay do not conflict, and
consider adding pointer-events:none to the overlay if it should not block
interactions.
What
Why
Additional info (optional)
Checklist
Summary by CodeRabbit
リリースノート
改善
修正
その他