Allow any Font Awesome style for the OAuth2 button icon (#7641)

[dpage]

Summary

Fixes #7641.

The login page hardcoded the fab (brands) Font Awesome style for the OAuth2 button icon (<Icon className={'fab '+oauth.OAUTH2_ICON} ...>), so administrators couldn't use non-brand icons (e.g. a generic fas fa-key for a custom provider).

Now the configured OAUTH2_ICON is used as-is when it already includes a style class, and falls back to fab when only an icon name is given — preserving existing configurations.

Changes

• LoginPage.jsx: derive the icon class from OAUTH2_ICON, defaulting to fab only when no style is present.
• oauth2.rst: document that a style class can be included.
• Added release note (9.16).

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • OAuth2 login button icons now support any Font Awesome style (e.g., fas fa-key), not just brand icons.

• Documentation

  • Updated OAuth2 icon configuration documentation with clarifications on Font Awesome style usage.
  • Added release notes entry for the new OAuth2 icon style support feature.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: dbb2a76e-8cc5-4f73-b131-f98587dc43aa

📥 Commits

Reviewing files that changed from the base of the PR and between 9052489 and 1eb4e26.

📒 Files selected for processing (2)

• docs/en_US/oauth2.rst
• docs/en_US/release_notes_9_16.rst

---

Walkthrough

The OAuth2 login button in LoginPage.jsx is updated to detect known Font Awesome style tokens in the configured OAUTH2_ICON value and use the icon class as-is when a style prefix is present, falling back to prepending fab for backward compatibility. The OAUTH2_ICON documentation and release notes for 9.16 are updated to reflect this expanded support.

Changes

OAuth2 Font Awesome Icon Style Support

Layer / File(s)	Summary
OAuth2 icon style detection in LoginPage web/pgadmin/static/js/SecurityPages/LoginPage.jsx	Icon class is now computed by checking the configured OAUTH2_ICON for known FA style tokens (fab, fas, far, fal, fad); if a token is found, the value is used directly; otherwise fab is prepended for backward compatibility.
Documentation and release notes docs/en_US/oauth2.rst, docs/en_US/release_notes_9_16.rst	OAUTH2_ICON parameter description updated to clarify brand icon default and explicit style class requirement for non-brand icons; release notes entry added for Issue #7641.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: enabling Font Awesome styles beyond the hardcoded 'fab' for OAuth2 button icons.
Linked Issues check	✅ Passed	The PR directly addresses issue #7641 by modifying LoginPage.jsx to detect and preserve Font Awesome style prefixes in configured icon values, enabling non-brand icons as requested.
Out of Scope Changes check	✅ Passed	All changes are scoped to the issue: LoginPage.jsx icon logic, oauth2.rst documentation clarity, and release notes for version 9.16.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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]

🧹 Nitpick comments (1)

web/pgadmin/static/js/SecurityPages/LoginPage.jsx (1)

52-53: 💤 Low value

Consider adding Font Awesome 6 Sharp family styles for completeness.

The iconStyles array covers standard Font Awesome 6 styles but omits the Sharp family variants: fa-sharp-solid, fa-sharp-regular, fa-sharp-light, and fa-sharp-thin. While these are premium/less common styles, adding them would make the detection more comprehensive for users with Font Awesome Pro licenses.

✨ Optional enhancement for Sharp styles

 const iconStyles = ['fab', 'fas', 'far', 'fal', 'fat', 'fad',
-  'fa-brands', 'fa-solid', 'fa-regular', 'fa-light', 'fa-thin', 'fa-duotone'];
+  'fa-brands', 'fa-solid', 'fa-regular', 'fa-light', 'fa-thin', 'fa-duotone',
+  'fa-sharp-solid', 'fa-sharp-regular', 'fa-sharp-light', 'fa-sharp-thin'];

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@web/pgadmin/static/js/SecurityPages/LoginPage.jsx` around lines 52 - 53, The
iconStyles array in LoginPage.jsx (variable name iconStyles) misses Font Awesome
6 Sharp family variants; update the array to include the sharp prefixes (e.g.,
'fa-sharp-solid', 'fa-sharp-regular', 'fa-sharp-light', 'fa-sharp-thin') so
detection covers Sharp styles as well — locate the iconStyles definition and
append these four strings to the list.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@web/pgadmin/static/js/SecurityPages/LoginPage.jsx`:
- Around line 52-53: The iconStyles array in LoginPage.jsx (variable name
iconStyles) misses Font Awesome 6 Sharp family variants; update the array to
include the sharp prefixes (e.g., 'fa-sharp-solid', 'fa-sharp-regular',
'fa-sharp-light', 'fa-sharp-thin') so detection covers Sharp styles as well —
locate the iconStyles definition and append these four strings to the list.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a2b504fc-fc64-42e2-89d2-82107965ee96

📥 Commits

Reviewing files that changed from the base of the PR and between 937d34e and 9052489.

📒 Files selected for processing (4)

• docs/en_US/oauth2.rst
• docs/en_US/release_notes.rst
• docs/en_US/release_notes_9_16.rst
• web/pgadmin/static/js/SecurityPages/LoginPage.jsx

[Copilot]

Pull request overview

This PR fixes pgAdmin’s OAuth2 login button icon rendering to support any Font Awesome style class (not just fab), while preserving backward compatibility for existing configurations that only provide an icon name.

Changes:

• Update LoginPage.jsx to use OAUTH2_ICON as-is when it already includes a Font Awesome style class; otherwise default to fab.
• Clarify OAuth2 documentation to note that OAUTH2_ICON may include an explicit style class (e.g. fas fa-key).
• Add a 9.16 release note entry referencing Issue #7641.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
web/pgadmin/static/js/SecurityPages/LoginPage.jsx	Implements style-aware OAUTH2_ICON handling with a backward-compatible fab fallback.
docs/en_US/oauth2.rst	Documents that OAUTH2_ICON may include a style class to select non-brand icons.
docs/en_US/release_notes_9_16.rst	Adds a release note entry for Issue #7641 describing the enhancement.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[asheshv]

No XSS — the value is rendered as className (not HTML), so this is fine. Two functional issues:

1. Coverage gap. The iconStyles list includes the old aliases fad / fas / fab / fal / far but omits fa-duotone, fa-sharp, and fa-sharp-duotone from the FA6 prefixing convention. A user who configures fa-sharp fa-key falls through hasStyle, gets 'fab ' prepended, and silently sees the wrong icon. Either extend the list or replace it with a forward-compatible regex like /^fa[a-z-]*$/.
2. iconStyles declared inside the .map() callback. Reallocated per-render per-provider. With one OAuth2 provider it's trivial, but hoist to module scope — it's a stable constant.