The enabled and allowFrom fields were accepted by the schema but not consumed by Mattermost runtime code, which could mislead operators into thinking group access was restricted when it was not.
The Mattermost channel config schema was missing the groups property, causing config validation to reject per-group requireMention settings with 'must NOT have additional properties' after upgrading to v2026.3.28. Adds MattermostGroupSchema with requireMention, enabled, and allowFrom fields, matching the pattern used by other channel plugins (IRC, Matrix, Feishu).
* fix(cron): prevent agent default model from overriding cron payload model (#58065)
When a cron job specifies a model override via the Advanced settings,
runWithModelFallback could silently fall back to the agent's configured
primary model. This happened because fallbacksOverride was undefined
when neither payload.fallbacks nor per-agent fallbacks were configured,
causing resolveFallbackCandidates to append the agent primary as a
last-resort candidate. A transient failure on the cron-selected model
(rate limit, model-not-found, etc.) would then succeed on the agent
default, making it appear as if the override was ignored entirely.
Fix: when the cron payload carries an explicit model override, ensure
fallbacksOverride is always a defined array (empty when no fallbacks
are configured) so the agent primary is never silently appended.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* test: use stricter toEqual([]) assertion for fallbacksOverride
Replace toBeDefined() + toBeInstanceOf(Array) with toEqual([])
to catch regressions where the array unexpectedly gains entries.
Addresses review feedback.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: preserve cron override fallback semantics (#58294)
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
When the gateway client reconnects using a stored device token, it was
defaulting to ["operator.admin"] scopes instead of preserving the
previously authorized scopes from the stored token. This caused the
operator device token to be regenerated without operator.read scope,
breaking status/probe/health commands.
This fix:
1. Loads the stored scopes along with the stored token in selectConnectAuth
2. Uses the stored scopes when reconnecting with a valid device token
3. Falls back to explicitly requested scopes or default admin-only scope
when no stored scopes exist
Fixes#46000
