Fix Issue #4554 - Replace hardcoded colors with Theme variables in Notifications

[KostasKoukianakis]

PR Checklist

• - Unit and/or e2e tests for the changes that have been added (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Refactoring (no functional changes)
• Documentation
• Other:

What is the new behavior?

Before: Notification elements (filter buttons, unread notification borders, and backgrounds) used hardcoded Precious Plastic yellow colors (activeYellow and #fff0b4) regardless of the active theme.

After: Notification colors now dynamically adapt to the active theme:

• Precious Plastic (PP): Yellow (#fee77b)
• Project Kamp (PK): Green (#8ab57f)
• Fixing Fashion (FF): Red (#f82f03)

Changes Made:

1. NotificationListSupabase - "Unread" and "All" filter buttons now use theme.colors.primary instead of hardcoded activeYellow
2. NotificationItemSupabase - Unread notification borders use theme.colors.primary and backgrounds use 40% opacity of the primary color (replacing hardcoded #fff0b4 and activeYellow)

Visual Changes:

• Unread notifications display with colored borders matching the theme
• Unread notification backgrounds show a subtle tint (40% opacity) of the theme color
• Filter buttons ("Unread"/"All") highlight with the theme's primary color when active
• Read notifications maintain normal gray/background styling

Does this PR introduce a DB Schema Change or Migration?

• Yes
• No

Git Issues

Closes #4554

What happens next?

Thank you for the contribution! We will review it ASAP.

If you need more immediate feedback you can reach out to us on Discord in the Community Platform development channel.

[mariojsnunes]

Nice!
I see some changes from the other PR in here, should keep it separate.

[mariojsnunes]

I think this is fine, but I'm wondering if it would be better to have a "faded" color setting on the theme.
@dalibormrska, @jproberson any thoughts on that?

[benfurber]

So I think there's a much simplier approach for this.

Rather than new functions or calling useThemeUI.

Remove activeYellow from packages/themes/src/common/commonStyles.tsx. Use primary (which will automatically use the theme specific hex) and define primaryWithOpacity as a specific hex value in packages/themes/src/fixing-fashion/styles.tsx, packages/themes/src/project-kamp/styles.tsx and packages/themes/src/precious-plastic/styles.tsx

[mariojsnunes]

define primaryWithOpacity as a specific hex value in packages/themes/src/fixing-fashion/styles.tsx, packages/themes/src/project-kamp/styles.tsx and packages/themes/src/precious-plastic/styles.tsx

agree. maybe primaryFaded is a more common name for that, instead of primaryWithOpacity.

[jproberson]

Hey @KostasKoukianakis ,

Thanks for jumping in and wanting to help out, we really do appreciate it.

That said, we're going to close these PRs for now. I wanted to explain why so it doesn't feel like we're just shutting you down.

The main issue is that each PR has commits from your other branches mixed in. When we try to review one feature, we're seeing changes from unrelated work, which makes it hard to review anything in isolation.

We're a small team, and we just don't have the bandwidth to untangle overlapping changes across 6-7 PRs at once. We'd much rather work with you on one thing at a time, give you real feedback, and help you get integrated in our ecosystem.

If you want to keep contributing (and we hope you do), here's what we'd suggest: start fresh from master with one issue, keep that PR focused on just that work, and let's get it reviewed and merged before moving to the next one.

We're actively updating our contributing docs to make this clearer for everyone going forward.

Hope that all makes sense. Happy to chat if you have questions.