hugocasa 796230d90a fix(workspaces): add instance setting to disable workspace invite/add emails (#9643) ...

* feat(workspaces): add skip_email option to invite_user and add_user endpoints

The workspace invite_user and add_user API endpoints unconditionally sent
notification emails when SMTP was configured, with no way to suppress them
per-request. This is noise for automated workflows that programmatically add
users to workspaces.

Add an optional `skip_email: Option<bool>` field to `NewWorkspaceInvite` and
`NewWorkspaceUser`, following the existing pattern on `NewUser` used by
POST /api/users/create, and guard the `send_email_if_possible` calls with
`if !nu.skip_email.unwrap_or(false)`. The field is optional, so existing
clients are unaffected.

The auto-add code paths in workspaces_ee.rs (domain-based and instance-group
auto-add) are auto-triggered and take no API parameter, so they are left as-is.

Fixes WIN-2068

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(workspaces): make workspace invite/add emails toggleable via instance setting

Replace the per-request skip_email approach with an instance-level setting
`disable_workspace_invite_emails`. When enabled, the email notifications sent by
the workspace invite_user and add_user endpoints are suppressed. Useful for
instances where users are added programmatically (e.g. CI pipelines that fork
workspaces and add users) and the invite emails are noise.

Backend:
- Add `DISABLE_WORKSPACE_INVITE_EMAILS_SETTING` global setting constant.
- Guard the `send_email_if_possible` calls in invite_user and add_user with a
  read of that setting (via the existing `load_value_from_global_settings`
  helper). Defaults to false, so existing behavior is unchanged.
- Revert the per-request `skip_email` field on NewWorkspaceInvite /
  NewWorkspaceUser and the corresponding openapi additions.

Frontend:
- Expose the setting as a boolean toggle in the SMTP tab of the instance
  settings (superadmin).

The auto-add paths in workspaces_ee.rs are unaffected.

Fixes WIN-2068

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(frontend): gate disable_workspace_invite_emails toggle behind EE

Email delivery (send_email_if_possible) is a no-op outside the EE/private
build, so the toggle has no effect on a pure-OSS instance. Add `ee_only: ''`
to match the sibling SMTP settings: the toggle is grayed out (with an EE badge)
on non-EE instances instead of rendering as an active no-op control.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(frontend): don't EE-gate disable_workspace_invite_emails toggle

The earlier ee_only addition was based on the false premise that the
workspace invite/add emails are license-gated. They are not: SMTP
configuration (SmtpSettings) and email sending (send_email_if_possible)
have no enterpriseLicense check — they only require the closed-source
build with SMTP configured. The sibling smtp_settings carries ee_only: ''
but its smtp_connect field renders no SettingCard label, so that flag is
inert (no badge, no disable). On a plain boolean field ee_only is fully
active, which incorrectly grayed out the toggle and showed an EE badge.
Drop ee_only so the control matches the actual non-license-gated behavior.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-18 16:59:11 +02:00

..

src

fix(workspaces): add instance setting to disable workspace invite/add emails (#9643)

2026-06-18 16:59:11 +02:00

Cargo.toml

feat: Fork datatables (#8339)

2026-04-07 21:03:06 +00:00