fix: missing i18n translation for Trans#82
Conversation
Code Review by Qodo (Alpha)
1. `tsconfig` sets `strict` false
|
| "types": ["vitest/globals", "node"], | ||
| "allowJs": true, | ||
| "strict": true, | ||
| "strict": false, |
There was a problem hiding this comment.
1. tsconfig sets strict false 📘 Rule Violation
• The PR changes TypeScript configuration to disable strict mode, reducing type safety across the frontend codebase. • This directly conflicts with the requirement to use strict typing and avoid weakening the type system, increasing risk of runtime errors and inadvertent any/unsafe typing. • Re-enabling strict mode preserves the project’s intended strict type-checking guarantees.
Agent Prompt
## Issue description
The frontend TypeScript configuration disables `strict` mode (`"strict": false`), which violates the requirement to use strict typing and avoid weakening type safety.
## Issue Context
The compliance checklist requires strict TypeScript typing; disabling `strict` can allow unsafe typing patterns to slip in and hide type errors.
## Fix Focus Areas
- web/tsconfig.json[24-24]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| await sendEmail( | ||
| mail, | ||
| email, | ||
| false, | ||
| stepToken, | ||
| ) |
There was a problem hiding this comment.
2. Email code sent wrong 🐞 Bug
• New-email verification validates the user-entered mail but sends the verification code to the old email prop instead. • Because the backend request is tagged as phase: 'new_email', this can prevent users from receiving a code at the intended new address and block email changes.
Agent Prompt
### Issue description
On the "send code to new email" step, the code validates `mail` (new email input) but calls `sendEmail(email, false, stepToken)` using the old email prop. Since `sendEmail` uses `phase: 'new_email'` for `isOrigin=false`, the verification code can be sent to the wrong address and block the email-change flow.
### Issue Context
`sendEmail()` forwards the provided address directly to `sendVerifyCode()`, and selects the backend phase based on `isOrigin`.
### Fix Focus Areas
- web/app/account/(commonLayout)/account-page/email-change-modal.tsx[155-169]
- web/app/account/(commonLayout)/account-page/email-change-modal.tsx[61-70]
### Suggested change
- Replace the `sendEmail(email, false, stepToken)` call with `sendEmail(mail, false, stepToken)`.
- (Optional hardening) Have `sendEmail` return success/failure (or rethrow on failure) and only call `setStep(STEP.verifyNew)` when the send succeeds.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| i18nKey="table.empty.element.content" | ||
| ns="appLog" | ||
| components={{ | ||
| shareLink: <Link href={`${appDetail.site.app_base_url}${basePath}/${getWebAppType(appDetail.mode)}/${appDetail.site.access_token}`} className="text-util-colors-blue-blue-600" target="_blank" rel="noopener noreferrer" />, | ||
| testLink: <Link href={getRedirectionPath(true, appDetail)} className="text-util-colors-blue-blue-600" />, | ||
| testLink: <Link href={getRedirectionPath(false, appDetail)} className="text-util-colors-blue-blue-600" />, | ||
| }} |
There was a problem hiding this comment.
3. Logs empty link misroutes 🐞 Bug
• The empty logs screen now hardcodes getRedirectionPath(false, appDetail) which always routes to /overview. • The logs route is already guarded to editors; routing editors to overview instead of configuration/workflow breaks the expected "test the app" navigation from logs.
Agent Prompt
### Issue description
The empty logs CTA now calls `getRedirectionPath(false, ...)`, which always routes to `/overview`. But the logs route is guarded to editors, so the CTA should route to editor pages (`/workflow` or `/configuration`) when testing the app.
### Issue Context
`getRedirectionPath` uses its boolean parameter to decide whether to route to editor pages vs overview.
### Fix Focus Areas
- web/app/components/app/log/empty-element.tsx[35-43]
- web/utils/app-redirection.ts[3-15]
### Suggested change
- Prefer: import `useAppContext()` and pass `isCurrentWorkspaceEditor` into `getRedirectionPath(isCurrentWorkspaceEditor, appDetail)`.
- If logs are truly editor-only everywhere, revert the hardcoded argument back to `true`.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| const sendCodeToOriginEmail = async () => { | ||
| await sendEmail() | ||
| setStep(STEP.verify) | ||
| await sendEmail() | ||
| } |
There was a problem hiding this comment.
4. Ownership token race 🐞 Bug
• The modal transitions to the verify step before the async send finishes, so the verify UI can render while stepToken is still empty. • This makes it possible to submit a code with an empty/stale token (e.g., fast paste / repeated attempts), causing avoidable verification failures.
Agent Prompt
### Issue description
`setStep(STEP.verify)` now happens before the async email-send finishes. This can render the verify screen before `stepToken` is available, allowing verification requests with an empty/stale token.
### Issue Context
`stepToken` is set only after `sendOwnerEmail()` resolves; verification passes `stepToken` as `token`.
### Fix Focus Areas
- web/app/components/header/account-setting/members-page/transfer-ownership-modal/index.tsx[94-101]
- web/app/components/header/account-setting/members-page/transfer-ownership-modal/index.tsx[54-67]
### Suggested change
- Revert ordering: `await sendEmail(); setStep(STEP.verify);`.
- Add `isSending` state: show loading/disable Continue/Resend until `stepToken` is set.
- Consider having `sendEmail()` return the token (or throw on failure) so the caller can gate the step transition on success.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Benchmark PR from qodo-benchmark#137