Fix Role class path for ::getNavigationIcon()

[rmartinoscar]

Filament v4 changed the folder architecture.

[coderabbitai]

📝 Walkthrough

Walkthrough

Centralizes navigation icon resolution: RoleResource.php now calls Role::getModelIcon($model) instead of multi-branch class_exists logic; Role model adds default and customizable model-icon mappings plus registration and retrieval APIs.

Changes

Cohort / File(s)	Summary
Model icon API app/Models/Role.php	Adds MODEL_ICONS constant, a protected static $customModelIcons, and two public methods: registerCustomModelIcon(string $model, string $icon): void and getModelIcon(string $model): ?string to manage and resolve model-to-icon mappings (prefers custom, then defaults, then fallback resolution).
Resource icon lookup update app/Filament/Admin/Resources/Roles/RoleResource.php	Replaces the prior multi-branch class_exists-based icon inference with a single call to Role::getModelIcon($model) to obtain the navigation icon.

Pre-merge checks

❌ Failed checks (2 warnings, 1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title mentions fixing a class path for getNavigationIcon(), but the actual changes implement a centralized icon lookup system with new MODEL_ICONS constant and methods in the Role model.	Update title to reflect the main change: 'Centralize model icon resolution in Role class' or 'Add centralized icon lookup system for models'.
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Description check	❓ Inconclusive	The description mentions Filament v4 folder architecture changes, which relates to the underlying reason for the refactor but is vague and doesn't explain the actual implementation changes.	Expand description to explain the new icon resolution system: add details about the MODEL_ICONS constant, custom icon registration, and centralized getModelIcon() method.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

app/Models/Role.php (2)

88-94: Custom icon registry matches existing extension pattern

The static $customModelIcons store plus registerCustomModelIcon() mirror the existing registerCustomPermissions() approach and correctly allow overrides on a per‑model basis. The overwrite semantics on repeat registration are reasonable; only optional improvement would be to add a way to clear this registry in tests if you ever need isolation between test cases.

---

141-164: Icon resolution order looks good; consider name normalization & confirm null contract

The resolution order (custom → defaults → Admin resource → Admin page → Server resource → null) matches the intended behavior and the new panel‑specific namespaces look consistent with how RoleResource is namespaced.

Two small follow‑ups to consider:

• Using ucwords($model) plus a naïve 's' suffix can be brittle if any model keys ever contain underscores/dashes or are already pluralized (e.g. "activity_log", "settings"). Using Laravel’s Str::studly($model) would be more robust if you expect such keys.
• getModelIcon() explicitly returns ?string; ensure all current call sites (e.g. section ->icon() usage) accept null and behave as expected when no icon is resolved. If you always want an icon, you might add a final fallback (e.g. 'tabler-help-circle').

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 98dc593 and d8f7b03.

📒 Files selected for processing (2)

• app/Filament/Admin/Resources/Roles/RoleResource.php (1 hunks)
• app/Models/Role.php (3 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

app/Models/Role.php (1)

app/Filament/Admin/Pages/Health.php (2)

• icon (163-172)
• getNavigationIcon (129-139)

app/Filament/Admin/Resources/Roles/RoleResource.php (1)

app/Models/Role.php (2)

• Role (24-183)
• getModelIcon (141-164)

🔇 Additional comments (2)

app/Models/Role.php (1)

57-61: Static MODEL_ICONS mapping is clear and consistent

The built‑in mapping for health, activityLog, and panelLog aligns with the permission keys and gives you stable icons regardless of how the underlying Filament page/resource chooses its navigation icon. No issues here.

app/Filament/Admin/Resources/Roles/RoleResource.php (1)

174-174: Nice centralization of icon resolution

Wiring Section::icon() through Role::getModelIcon($model) removes the ad‑hoc class resolution from this resource and keeps icon logic in one place. Assuming Section::icon() tolerates null (for models without an icon), this looks solid; otherwise you may want a fallback icon there.