Settings handler split — breaking change

Date : 2026-04-24 Scope : rustwarden-ui — reorganisation interne des handlers /settings/* Comportement runtime : inchange (memes routes HTTP, memes responses) Breaking change : oui, pour les apps consommatrices qui importent directement des symboles de rustwarden_ui::handlers::settings_handler

Contexte

Le fichier crates/rustwarden-ui/src/handlers/settings_handler.rs grossit de facon continue (profil utilisateur, changement de mot de passe, sessions actives, preferences, 2FA...). Apres la branche AddTeams, il atteignait ~1673 lignes — difficile a relire, et chaque evolution touchait un fichier monolithique.

Cette modification repartit les handlers par domaine fonctionnel dans un sous-module :

crates/rustwarden-ui/src/handlers/
├── settings/
│   ├── mod.rs          # NavItem, build_nav_items_from_dto, filters Askama partages
│   ├── profile.rs      # profil utilisateur (username, email, avatar)
│   ├── security.rs     # mot de passe, sessions actives, entree 2FA
│   └── preferences.rs  # locale, theme, notifications

Le fichier settings_handler.rs est supprime.

Migration des imports

Les apps consommatrices qui importent directement des symboles doivent adapter leurs use.

Symbole	Ancien chemin	Nouveau chemin
`update_profile`	`rustwarden_ui::handlers::settings_handler::update_profile`	`rustwarden_ui::handlers::settings::profile::update_profile`
`get_profile_page`	`rustwarden_ui::handlers::settings_handler::get_profile_page`	`rustwarden_ui::handlers::settings::profile::get_profile_page`
`UpdateProfileRequest`	`rustwarden_ui::handlers::settings_handler::UpdateProfileRequest`	`rustwarden_ui::handlers::settings::profile::UpdateProfileRequest`
`ProfileTemplate`	`rustwarden_ui::handlers::settings_handler::ProfileTemplate`	`rustwarden_ui::handlers::settings::profile::ProfileTemplate`
`change_password`	`rustwarden_ui::handlers::settings_handler::change_password`	`rustwarden_ui::handlers::settings::security::change_password`
`confirm_password_change`	`rustwarden_ui::handlers::settings_handler::confirm_password_change`	`rustwarden_ui::handlers::settings::security::confirm_password_change`
`cancel_pending_password_change`	`rustwarden_ui::handlers::settings_handler::cancel_pending_password_change`	`rustwarden_ui::handlers::settings::security::cancel_pending_password_change`
`list_sessions`	`rustwarden_ui::handlers::settings_handler::list_sessions`	`rustwarden_ui::handlers::settings::security::list_sessions`
`revoke_session`	`rustwarden_ui::handlers::settings_handler::revoke_session`	`rustwarden_ui::handlers::settings::security::revoke_session`
`get_password_page`	`rustwarden_ui::handlers::settings_handler::get_password_page`	`rustwarden_ui::handlers::settings::security::get_password_page`
`get_sessions_page`	`rustwarden_ui::handlers::settings_handler::get_sessions_page`	`rustwarden_ui::handlers::settings::security::get_sessions_page`
`ChangePasswordRequest`	`rustwarden_ui::handlers::settings_handler::ChangePasswordRequest`	`rustwarden_ui::handlers::settings::security::ChangePasswordRequest`
`ChangePasswordResponse`	`rustwarden_ui::handlers::settings_handler::ChangePasswordResponse`	`rustwarden_ui::handlers::settings::security::ChangePasswordResponse`
`ActiveSessionsResponse`	`rustwarden_ui::handlers::settings_handler::ActiveSessionsResponse`	`rustwarden_ui::handlers::settings::security::ActiveSessionsResponse`
`PasswordPageQuery`	`rustwarden_ui::handlers::settings_handler::PasswordPageQuery`	`rustwarden_ui::handlers::settings::security::PasswordPageQuery`
`ConfirmPasswordChangeQuery`	`rustwarden_ui::handlers::settings_handler::ConfirmPasswordChangeQuery`	`rustwarden_ui::handlers::settings::security::ConfirmPasswordChangeQuery`
`PasswordTemplate`	`rustwarden_ui::handlers::settings_handler::PasswordTemplate`	`rustwarden_ui::handlers::settings::security::PasswordTemplate`
`SessionsTemplate`	`rustwarden_ui::handlers::settings_handler::SessionsTemplate`	`rustwarden_ui::handlers::settings::security::SessionsTemplate`
`get_preferences`	`rustwarden_ui::handlers::settings_handler::get_preferences`	`rustwarden_ui::handlers::settings::preferences::get_preferences`
`update_preferences`	`rustwarden_ui::handlers::settings_handler::update_preferences`	`rustwarden_ui::handlers::settings::preferences::update_preferences`
`get_preferences_page`	`rustwarden_ui::handlers::settings_handler::get_preferences_page`	`rustwarden_ui::handlers::settings::preferences::get_preferences_page`
`UpdatePreferencesRequest`	`rustwarden_ui::handlers::settings_handler::UpdatePreferencesRequest`	`rustwarden_ui::handlers::settings::preferences::UpdatePreferencesRequest`
`PreferencesTemplate`	`rustwarden_ui::handlers::settings_handler::PreferencesTemplate`	`rustwarden_ui::handlers::settings::preferences::PreferencesTemplate`

Ce qui n'a PAS change

Les routes HTTP : /profile, /settings/password, /settings/sessions, /settings/preferences, /settings/security/* sont toutes preservees, memes methodes, memes responses.
Les templates Askama : templates/settings/*.html sont inchanges.
Le comportement : aucune logique metier modifiee, aucune regression fonctionnelle attendue. Tests existants passent tels quels.
Les handlers TOTP / 2FA : deja dans handlers/totp_handler.rs, hors du champ de cette reorganisation.

Comment adapter

Si votre app consommatrice n'importe aucun symbole de settings_handler directement (cas le plus frequent, vous utilisez juste rustwarden_ui::default_routes), il n'y a rien a faire. Le serveur continue de servir les memes pages.

Sinon, recherche-remplace global dans votre code :

settings_handler:: → settings::profile::    # pour profil
settings_handler:: → settings::security::   # pour password/sessions
settings_handler:: → settings::preferences:: # pour theme/locale

Ou bien, pour un filet de compatibilite local temporaire dans votre app :

// Compat shim local — a retirer une fois tous vos imports adaptes
pub use rustwarden_ui::handlers::settings::preferences;
pub use rustwarden_ui::handlers::settings::profile;
pub use rustwarden_ui::handlers::settings::security;

Pourquoi ce split maintenant

Decide pendant la resolution de dette technique post-audit AddTeams (voir docs/plans/2026-04-24-post-audit-addteams-debt.md). Le fichier monolithique etait identifie comme dette prioritaire : chaque nouvelle fonctionnalite (2FA, Teams, preferences etendues) l'agrandissait sans que les domaines soient clairement separes. Le Product Owner a retenu l'option "Un sous-module par section (dossier)" pour preparer les futures extensions (notifications, webhooks...) sans toucher le meme fichier.