fix: Updated translation key usage in change password error scenario

[utkershrajvenshi]

Description

Updated translation keys being used in toast component invokation in change password catch block. Fixes #8082

Type of Change

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] Feature (non-breaking change which adds functionality)
• [ ] Improvement (change that would cause existing functionality to not work as expected)
• [ ] Code refactoring
• [ ] Performance improvements
• [ ] Documentation update

Screenshots and Media (if applicable)

Test Scenarios

References

---

[!NOTE] Use change_password-specific i18n keys for error toast in the account security password change flow.

^{Written by Cursor Bugbot for commit 76028319a24dd4409c7b47bde08f0a924e5c05c5. This will update automatically on new commits. Configure here.}

Summary by CodeRabbit

• Bug Fixes
  • Improved error message accuracy during password change operations by displaying more contextually relevant authentication error notifications.

[CLAassistant]

All committers have signed the CLA.

[coderabbitai[bot]]

Walkthrough

The SecurityPage component's error handling was updated to display password change-specific error translations instead of generic password error keys, ensuring appropriate error messages appear when authentication errors occur during the password change process.

Changes

Cohort / File(s)	Change Summary
Error translation key updates apps/web/app/(all)/[workspaceSlug]/(settings)/settings/account/security/page.tsx	Updated error toast title and message to use change_password translation keys instead of generic password keys for improved error messaging during password changes

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Single file change affecting only error message translation keys
• No logic modifications or control-flow alterations
• Straightforward string substitution for improved error messaging alignment

Poem

🐰 A password changed, now errors sing clear, No cryptic keys to fill hearts with fear, From generic to specific, the message takes flight, Error handling polished, passwords set right! 🔐

Pre-merge checks and finishing touches

❌ 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%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: updating translation key usage for change password error scenarios.
Description check	✅ Passed	The description covers the bug fix type, references the linked issue #8082, but lacks test scenarios and screenshots sections.
Linked Issues check	✅ Passed	The PR updates translation keys in the change password error handler to use change_password-specific i18n keys instead of generic password keys, directly addressing the root cause of issue #8082 where translation keys were displayed instead of user-friendly error messages.
Out of Scope Changes check	✅ Passed	The change is limited to updating translation key references in the SecurityPage password change error handler, remaining focused on the scope of issue #8082 without introducing unrelated modifications.

✨ Finishing touches

• [ ] 📝 Generate docstrings

🧪 Generate unit tests (beta)

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment

---

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.}

[utkershrajvenshi]

Actual observation related to backend password check described in linked issue still stands unresolved. Converting to draft PR for now.

[utkershrajvenshi]

Verified the issue author's findings. On backend the package zxcvbn is performing common pattern matching to determine if the entered password is complex enough to be considered strong, this is the output with sample value Say!hello1:

{
    "password": "Say!hello1",
    "guesses": "8870000",
    "guesses_log10": 6.947923619831726,
    "sequence": [
        {
            "pattern": "bruteforce",
            "token": "Say!",
            "i": 0,
            "j": 3,
            "guesses": 10000,
            "guesses_log10": 4.0
        },
        {
            "pattern": "dictionary",
            "i": 4,
            "j": 9,
            "token": "hello1",
            "matched_word": "hello1",
            "rank": 443,
            "dictionary_name": "passwords",
            "reversed": false,
            "l33t": false,
            "base_guesses": 443,
            "uppercase_variations": 1,
            "l33t_variations": 1,
            "guesses": 443,
            "guesses_log10": 2.6464037262230695
        }
    ],
    "calc_time": 0.000694,
    "crack_times_seconds": {
        "online_throttling_100_per_hour": "319320000.0000000177258208112",
        "online_no_throttling_10_per_second": "887000",
        "offline_slow_hashing_1e4_per_second": "887",
        "offline_fast_hashing_1e10_per_second": "0.000887"
    },
    "crack_times_display": {
        "online_throttling_100_per_hour": "10 years",
        "online_no_throttling_10_per_second": "10 days",
        "offline_slow_hashing_1e4_per_second": "15 minutes",
        "offline_fast_hashing_1e10_per_second": "less than a second"
    },
    "score": 2,
    "feedback": {
        "warning": "This is similar to a commonly used password.",
        "suggestions": [
            "Add another word or two. Uncommon words are better."
        ]
    }
}

On frontend, only basic structural validation checks are being used for entered passwords.

Either we can use zxcvbn npm package on frontend, or to maintain structural validation on both ends, use the getPasswordStrength helper function from utils.

@vihar what's your take?