Skip to content

v0.7.4

Choose a tag to compare

@jaspertey jaspertey released this 30 Oct 13:48
6dfc0b3

Upgrading

  • Run kit:update plan|apply for session-ui (re-pinned sha256:592e21c4…7353 → sha256:c59375ef…dd74): Auth/Login, Auth/ForgotPassword, Auth/ResetPassword, Auth/ConfirmPassword and Auth/VerifyEmail take the auth-state fixes below. ResetPasswordViewModel gains status; a host that hand-copies types/kit.d.ts copies it again. A host overriding lang/vendor/kit/{locale}/ui.php can add form.throttled and form.throttled_retry.
  • kit.people.hide_grants needs tey/concierge 0.9.3 or later, for MembersIndex::scopeMembersUsing(). With no hidden grants nothing changes on any Concierge the workspaces feature allows (^0.8.4 || ^0.9); with some on an older one, the app refuses to boot ("kit.people.hide_grants needs tey/concierge 0.9.3 or later"), never a page. The kit's own checks now resolve Concierge ^0.8.4 || ^0.9 (was ^0.8.4), the range the workspaces feature already allows. No stub changes, no re-pin.

Added

  • kit.people.hide_grants: a list of Concierge grants (roles) whose holders the people lists leave out, such as a support role (docs/dashboard.md › Hiding people by grant). A member holding one of them in the workspace is absent from Settings › People (rows and the Members count alike), the People widget and people search, and their own Change role and Transfer ownership pages, role change and removal by id are a 404. The default is []; a value that isn't a list of names is refused at boot. composer test:people-hide-grants (new, in CI) covers each surface.

Changed

  • The auth forms validate in the card, not in the browser. Auth/Login, Auth/ForgotPassword, Auth/ResetPassword and Auth/ConfirmPassword carry novalidate, so the server's field errors render in the card (an address like "nobody" gets the "valid email address" error) instead of the browser's own bubble. The fields keep type="email", required and autocomplete.

Fixed

  • The guest auth pages keep a rate-limited submit in the card. A 429 from a limiter (Fortify's login limiter, the verification resend, a reset or reset-link request) opened Inertia's error modal over the page. Auth/Login, Auth/ForgotPassword, Auth/ResetPassword, Auth/ConfirmPassword and Auth/VerifyEmail now refuse the modal for a 429 only (onHttpException returns false), clear the stale field errors and show an in-card alert (role="alert"): "Too many requests. Try again in N seconds." when the response carries Retry-After, else "Too many requests. Try again in a moment." The copy is in the kit's ui lang file (form.throttled, form.throttled_retry). Any other HTTP error still gets Inertia's modal; nothing the server allows or limits changes.
  • A failed sign-in, reset or confirmation clears the password and marks the field. Auth/Login, Auth/ResetPassword and Auth/ConfirmPassword reset their password fields on error, set aria-invalid on the fields with an error, and move focus to the first one (the email after bad credentials).
  • A bad or expired reset token is visible. Fortify reports it on email, a hidden field on Auth/ResetPassword, so nothing showed. It now shows as an in-card alert with a "Request a new link" link to /forgot-password.
  • The reset-password page's status comes from its view model. ResetPasswordViewModel takes status (the flashed session status), so the FormStatus on that page shows the server's status without the host supplying it.
  • The sign-in page focuses the email field on load, as Auth/ConfirmPassword already focuses the password.

What's Changed

Full Changelog: v0.7.3...v0.7.4