Overview - Zitadel/zitadel

zitadel/zitadel

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
chore/dep-updates
a25761e4 lint
3 days ago by Max Peintner
Failed
chore/dep-updates
3527f089 remove setnextheme from dep array, since it fired twrice and broke theming
3 days ago by Max Peintner
Succeeded
main
891c7473 fix(login): invite flow instead of email verification for users with no primary method, improve sending behaviour (#11837) Closes #10929 # Which Problems Are Solved When a human user without a primary authentication method enters their email on the login screen, the login historically auto-sent an email code (send=true) and redirected them to the `/verify` flow. If the user was newly created via the API and already received an initial verify-email, navigating to the login page would trigger a new invite code, silently invalidating the code they received in their first email. Additionally instead of resending the same type of email (invitation) a regular email verification mail was sent # How the Problems Are Solved - Resend an invitation email instead of a email verification if a user has no method set (still in invitation state) - Conditional Code Sending: Updated `loginname.ts` to check `humanUser?.email?.isVerified`. We only auto-send a new code (`send=true`) if the user's email is already verified. Unverified users will be redirected with `send=false`, allowing them to safely enter the code they already have. - UI State Fix: Fixed an issue in `verify/page.tsx` where the send URL parameter was being checked directly as a string ("false" is truthy). By using the properly evaluated doSend boolean, the "Code Sent" alert now correctly hides itself when a new code is not explicitly sent. - Translation Updates: Refined the codeSent messaging across all locales to specify "A new code has been sent..." to provide better context to the user when they do explicitly request a resend.
3 days ago by Max Peintner
Succeeded
lgn-swr-id
c65e4dd6 fix(login): invite flow instead of email verification for users with no primary method, improve sending behaviour (#11837) Closes #10929 # Which Problems Are Solved When a human user without a primary authentication method enters their email on the login screen, the login historically auto-sent an email code (send=true) and redirected them to the `/verify` flow. If the user was newly created via the API and already received an initial verify-email, navigating to the login page would trigger a new invite code, silently invalidating the code they received in their first email. Additionally instead of resending the same type of email (invitation) a regular email verification mail was sent # How the Problems Are Solved - Resend an invitation email instead of a email verification if a user has no method set (still in invitation state) - Conditional Code Sending: Updated `loginname.ts` to check `humanUser?.email?.isVerified`. We only auto-send a new code (`send=true`) if the user's email is already verified. Unverified users will be redirected with `send=false`, allowing them to safely enter the code they already have. - UI State Fix: Fixed an issue in `verify/page.tsx` where the send URL parameter was being checked directly as a string ("false" is truthy). By using the properly evaluated doSend boolean, the "Code Sent" alert now correctly hides itself when a new code is not explicitly sent. - Translation Updates: Refined the codeSent messaging across all locales to specify "A new code has been sent..." to provide better context to the user when they do explicitly request a resend.
4 days ago by Max Peintner
Succeeded
lgn-swr-id
c65e4dd6 Merge e7e9bbcc093a0b16a24d21320fa07c3bbd22c760 into 891c7473ca222a99811a3b3e7e4d7b15d8ec6d1c
4 days ago by Max Peintner
Succeeded
main
891c7473 fix(login): invite flow instead of email verification for users with no primary method, improve sending behaviour (#11837) Closes #10929 # Which Problems Are Solved When a human user without a primary authentication method enters their email on the login screen, the login historically auto-sent an email code (send=true) and redirected them to the `/verify` flow. If the user was newly created via the API and already received an initial verify-email, navigating to the login page would trigger a new invite code, silently invalidating the code they received in their first email. Additionally instead of resending the same type of email (invitation) a regular email verification mail was sent # How the Problems Are Solved - Resend an invitation email instead of a email verification if a user has no method set (still in invitation state) - Conditional Code Sending: Updated `loginname.ts` to check `humanUser?.email?.isVerified`. We only auto-send a new code (`send=true`) if the user's email is already verified. Unverified users will be redirected with `send=false`, allowing them to safely enter the code they already have. - UI State Fix: Fixed an issue in `verify/page.tsx` where the send URL parameter was being checked directly as a string ("false" is truthy). By using the properly evaluated doSend boolean, the "Code Sent" alert now correctly hides itself when a new code is not explicitly sent. - Translation Updates: Refined the codeSent messaging across all locales to specify "A new code has been sent..." to provide better context to the user when they do explicitly request a resend.
4 days ago by Max Peintner
Failed
feat/ecdsa-ed25519-public-keys
16861f96 fix(login): invite flow instead of email verification for users with no primary method, improve sending behaviour (#11837) Closes #10929 # Which Problems Are Solved When a human user without a primary authentication method enters their email on the login screen, the login historically auto-sent an email code (send=true) and redirected them to the `/verify` flow. If the user was newly created via the API and already received an initial verify-email, navigating to the login page would trigger a new invite code, silently invalidating the code they received in their first email. Additionally instead of resending the same type of email (invitation) a regular email verification mail was sent # How the Problems Are Solved - Resend an invitation email instead of a email verification if a user has no method set (still in invitation state) - Conditional Code Sending: Updated `loginname.ts` to check `humanUser?.email?.isVerified`. We only auto-send a new code (`send=true`) if the user's email is already verified. Unverified users will be redirected with `send=false`, allowing them to safely enter the code they already have. - UI State Fix: Fixed an issue in `verify/page.tsx` where the send URL parameter was being checked directly as a string ("false" is truthy). By using the properly evaluated doSend boolean, the "Code Sent" alert now correctly hides itself when a new code is not explicitly sent. - Translation Updates: Refined the codeSent messaging across all locales to specify "A new code has been sent..." to provide better context to the user when they do explicitly request a resend.
4 days ago by Max Peintner
Succeeded
main
891c7473 fix(login): invite flow instead of email verification for users with no primary method, improve sending behaviour (#11837) Closes #10929 # Which Problems Are Solved When a human user without a primary authentication method enters their email on the login screen, the login historically auto-sent an email code (send=true) and redirected them to the `/verify` flow. If the user was newly created via the API and already received an initial verify-email, navigating to the login page would trigger a new invite code, silently invalidating the code they received in their first email. Additionally instead of resending the same type of email (invitation) a regular email verification mail was sent # How the Problems Are Solved - Resend an invitation email instead of a email verification if a user has no method set (still in invitation state) - Conditional Code Sending: Updated `loginname.ts` to check `humanUser?.email?.isVerified`. We only auto-send a new code (`send=true`) if the user's email is already verified. Unverified users will be redirected with `send=false`, allowing them to safely enter the code they already have. - UI State Fix: Fixed an issue in `verify/page.tsx` where the send URL parameter was being checked directly as a string ("false" is truthy). By using the properly evaluated doSend boolean, the "Code Sent" alert now correctly hides itself when a new code is not explicitly sent. - Translation Updates: Refined the codeSent messaging across all locales to specify "A new code has been sent..." to provide better context to the user when they do explicitly request a resend.
4 days ago by Max Peintner
Succeeded
login-invite-flow
cb4f38b9 Merge 8c019245815ce626dd1e1345680b37ee37d0de0b into 140f07e60b01c302b0135bb082198b6bf58ea7f6
4 days ago by Max Peintner
Succeeded
lgn-swr-id
5e5bc9ae swr
5 days ago by Max Peintner
Succeeded
lgn-swr-id
5e5bc9ae Merge 98edce23fdde25b9ce1b4a998c5d9407a498d472 into 330548e13c34c57d7bda6ce66c0ecc560832c376
5 days ago by Max Peintner
Succeeded
main
ec0bd579 fix(login): respect branding themeMode for theme toggle, fix CSP (#11903) Closes #11721 # Which Problems Are Solved The login app now correctly handles the themeMode from branding settings: - Hide toggle when themeMode is LIGHT or DARK — the theme is forced, users cannot switch - Show 3-option toggle (light / system / dark) when themeMode is AUTO or UNSPECIFIED # How the Problems Are Solved - Introduced a `BrandingContext` to pass `themeMode` from `ThemeWrapper` down to `ThemeSwitch` # Additional Changes - removed the CSP from next.config.ts to prevent a precedency issue where the CSP was actually not applied
5 days ago by Max Peintner
Succeeded
fix-invalid-signature-error-handling
de002aee fix(login): respect branding themeMode for theme toggle, fix CSP (#11903) Closes #11721 # Which Problems Are Solved The login app now correctly handles the themeMode from branding settings: - Hide toggle when themeMode is LIGHT or DARK — the theme is forced, users cannot switch - Show 3-option toggle (light / system / dark) when themeMode is AUTO or UNSPECIFIED # How the Problems Are Solved - Introduced a `BrandingContext` to pass `themeMode` from `ThemeWrapper` down to `ThemeSwitch` # Additional Changes - removed the CSP from next.config.ts to prevent a precedency issue where the CSP was actually not applied
5 days ago by Max Peintner
Failed
chore/install-proto-plugins
e0efbd89 fix(login): respect branding themeMode for theme toggle, fix CSP (#11903) Closes #11721 # Which Problems Are Solved The login app now correctly handles the themeMode from branding settings: - Hide toggle when themeMode is LIGHT or DARK — the theme is forced, users cannot switch - Show 3-option toggle (light / system / dark) when themeMode is AUTO or UNSPECIFIED # How the Problems Are Solved - Introduced a `BrandingContext` to pass `themeMode` from `ThemeWrapper` down to `ThemeSwitch` # Additional Changes - removed the CSP from next.config.ts to prevent a precedency issue where the CSP was actually not applied
5 days ago by Max Peintner
Succeeded
main
ec0bd579 fix(login): respect branding themeMode for theme toggle, fix CSP (#11903) Closes #11721 # Which Problems Are Solved The login app now correctly handles the themeMode from branding settings: - Hide toggle when themeMode is LIGHT or DARK — the theme is forced, users cannot switch - Show 3-option toggle (light / system / dark) when themeMode is AUTO or UNSPECIFIED # How the Problems Are Solved - Introduced a `BrandingContext` to pass `themeMode` from `ThemeWrapper` down to `ThemeSwitch` # Additional Changes - removed the CSP from next.config.ts to prevent a precedency issue where the CSP was actually not applied
5 days ago by Max Peintner
Succeeded
fix/user-relational-passkey-verified
92fecea7 fix(login): respect branding themeMode for theme toggle, fix CSP (#11903) Closes #11721 # Which Problems Are Solved The login app now correctly handles the themeMode from branding settings: - Hide toggle when themeMode is LIGHT or DARK — the theme is forced, users cannot switch - Show 3-option toggle (light / system / dark) when themeMode is AUTO or UNSPECIFIED # How the Problems Are Solved - Introduced a `BrandingContext` to pass `themeMode` from `ThemeWrapper` down to `ThemeSwitch` # Additional Changes - removed the CSP from next.config.ts to prevent a precedency issue where the CSP was actually not applied
5 days ago by Max Peintner
Succeeded
main
ec0bd579 fix(login): respect branding themeMode for theme toggle, fix CSP (#11903) Closes #11721 # Which Problems Are Solved The login app now correctly handles the themeMode from branding settings: - Hide toggle when themeMode is LIGHT or DARK — the theme is forced, users cannot switch - Show 3-option toggle (light / system / dark) when themeMode is AUTO or UNSPECIFIED # How the Problems Are Solved - Introduced a `BrandingContext` to pass `themeMode` from `ThemeWrapper` down to `ThemeSwitch` # Additional Changes - removed the CSP from next.config.ts to prevent a precedency issue where the CSP was actually not applied
5 days ago by Max Peintner
Succeeded
login-invite-flow
e0bfebf6 fix(login): respect branding themeMode for theme toggle, fix CSP (#11903) Closes #11721 # Which Problems Are Solved The login app now correctly handles the themeMode from branding settings: - Hide toggle when themeMode is LIGHT or DARK — the theme is forced, users cannot switch - Show 3-option toggle (light / system / dark) when themeMode is AUTO or UNSPECIFIED # How the Problems Are Solved - Introduced a `BrandingContext` to pass `themeMode` from `ThemeWrapper` down to `ThemeSwitch` # Additional Changes - removed the CSP from next.config.ts to prevent a precedency issue where the CSP was actually not applied
5 days ago by Max Peintner
Succeeded
login-invite-flow
e0bfebf6 Merge f539114b8ae41a340f00b19eaa47ac28ef119652 into ec0bd5790f21ca367e7d6186098308ce1dec230c
5 days ago by Max Peintner
Succeeded
main
ec0bd579 fix(login): respect branding themeMode for theme toggle, fix CSP (#11903) Closes #11721 # Which Problems Are Solved The login app now correctly handles the themeMode from branding settings: - Hide toggle when themeMode is LIGHT or DARK — the theme is forced, users cannot switch - Show 3-option toggle (light / system / dark) when themeMode is AUTO or UNSPECIFIED # How the Problems Are Solved - Introduced a `BrandingContext` to pass `themeMode` from `ThemeWrapper` down to `ThemeSwitch` # Additional Changes - removed the CSP from next.config.ts to prevent a precedency issue where the CSP was actually not applied
5 days ago by Max Peintner