[cquirosj]

Builds on

• Explain that the stored SMTP password is never shown #3164

The email configuration dialog never shows the stored SMTP password, and nothing outside the dialog keeps it, with any ServiceControl version.

Behavior

• The dialog reads the current settings from ServiceControl each time it opens, so it shows changes made elsewhere since the page loaded.
• The password field always starts empty. Leaving it empty keeps the stored password; typing a new one replaces it. Removing the account also removes the password.
• If the settings can't be loaded, the dialog says so and can't be saved. This also fixes a problem Explain that the stored SMTP password is never shown #3164 introduced: it reloaded all settings into the page each time the dialog opened, and if that request failed, the switch dropped to OFF and the dialog opened with an empty form. Now only the dialog loads its settings, so a failed load can't change the switch.

Older ServiceControl versions backward compatibility

ServiceControl before 6.21.2 returns the stored password, and a save replaces it with whatever is sent, including an empty value. Since the password field starts empty, a routine edit such as changing the To address would erase the stored password, and health check emails would silently stop authenticating.

To prevent that, on these versions the dialog keeps the password from the settings it reads when it opens. It's held in memory only, never shown, and sent back if the field is left empty. It's dropped when the dialog closes.

ServiceControl 6.21.2 and later (Particular/ServiceControl#5980) don't return the password and keep the stored one when an empty password is sent, so the dialog has nothing to hold and sends the empty password. No version check is involved: the dialog sends back whatever ServiceControl returned, which is nothing on 6.21.2 and later.

Implementation note

The dialog reads and saves its own settings through ServiceControl's API, and everything it holds is dropped when it closes. The Pinia store keeps only page-level state: whether notifications are enabled and the permissions, plus the toggle and test-notification actions. The dialog's tests answer its requests through the mock server and check what is sent to ServiceControl.

Reviewer Checklist

• Components are broken down into sensible and maintainable sub-components.
• Styles are scoped to the component using it. If multiple components need to share CSS, then a .css file is created containing the shared CSS and imported into component scoped style sections.
• Naming is consistent with existing code, and adequately describes the component or function being introduced
• Only functions utilizing Vue state or lifecycle hooks are named as composables (i.e., starting with 'use');
• No module-level state is being introduced. If so, request the PR author to move the state to the corresponding Pinia store.

[PhilBastian]

This comment can be a bit misleading: 'closing' the dialog doesn't drop everything below, it's the v-if in the parent causing the component to no longer be part of the virtual DOM that causes this entire component state to be discarded.