Requested Content
Kanvas's Help & Support flow changed in layer5labs/meshery-extensions (support submissions now route through Meshery Server instead of posting from the browser to a third-party webhook). Two user-visible preconditions resulted, and neither is documented today - a search of this repo found no Kanvas Help & Support page at all.
1. Help & Support now requires a remote provider.
Submitting a support request traverses Meshery Server's extension proxy (POST /api/extensions/api/webhook/support). Under the local provider that proxy returns 501 Not Implemented (meshery/server/handlers/extensions.go maps ErrLocalProviderSupport to StatusNotImplemented), so Help & Support does not work without a remote provider.
Previously the form POSTed straight to a third-party webhook from the browser, so it worked under any provider. This brings it in line with every other Cloud-bound Kanvas feature - designs/views sharing, catalog, resource access - all of which already require a remote provider for the same reason.
Suggested placement: the Kanvas docs section covering Help & Support (creating one if none exists), noting the remote-provider requirement alongside the other provider-dependent features.
2. The form requires a signed-in identity.
Help & Support resolves the signed-in user's profile (/api/user) before the form becomes submittable, so the support request always carries a reply address. If the profile cannot be resolved, the form reports that and does not submit - a request with no way to reply is not sent. Users on a degraded or expired session should sign in again and retry.
3. Addendum for self-hosters (existing page).
content/en/cloud/guides/self-hosted/customizing-webhooks.md describes WEBHOOK_HELP_AND_SUPPORT as firing when "a user fills the help and support form". That remains true, but is now incomplete: self-hosted deployments will receive Kanvas-originated support tickets on that same webhook, not only tickets from the Layer5 Cloud Help & Support modal. Both arrive with the same memberFormOne payload shape, so no webhook-side change is needed - the note is so operators are not surprised by the new source.
Context
Source change: layer5labs/meshery-extensions - routes Kanvas support submissions through Meshery Server per a maintainer ruling that all Kanvas communication flows through Meshery Server. The previous client-side path sent the signed-in user's name and email cross-origin to a third-party webhook.
Related: meshery/schemas#1148 (support operation schema divergence), meshery/meshery#21227 (host modal Submit-disable gap).
Filing rather than opening a PR directly because the source change lives in another repo; happy for this to be picked up as the companion docs change.
Requested Content
Kanvas's Help & Support flow changed in layer5labs/meshery-extensions (support submissions now route through Meshery Server instead of posting from the browser to a third-party webhook). Two user-visible preconditions resulted, and neither is documented today - a search of this repo found no Kanvas Help & Support page at all.
1. Help & Support now requires a remote provider.
Submitting a support request traverses Meshery Server's extension proxy (
POST /api/extensions/api/webhook/support). Under the local provider that proxy returns 501 Not Implemented (meshery/server/handlers/extensions.gomapsErrLocalProviderSupporttoStatusNotImplemented), so Help & Support does not work without a remote provider.Previously the form POSTed straight to a third-party webhook from the browser, so it worked under any provider. This brings it in line with every other Cloud-bound Kanvas feature - designs/views sharing, catalog, resource access - all of which already require a remote provider for the same reason.
Suggested placement: the Kanvas docs section covering Help & Support (creating one if none exists), noting the remote-provider requirement alongside the other provider-dependent features.
2. The form requires a signed-in identity.
Help & Support resolves the signed-in user's profile (
/api/user) before the form becomes submittable, so the support request always carries a reply address. If the profile cannot be resolved, the form reports that and does not submit - a request with no way to reply is not sent. Users on a degraded or expired session should sign in again and retry.3. Addendum for self-hosters (existing page).
content/en/cloud/guides/self-hosted/customizing-webhooks.mddescribesWEBHOOK_HELP_AND_SUPPORTas firing when "a user fills the help and support form". That remains true, but is now incomplete: self-hosted deployments will receive Kanvas-originated support tickets on that same webhook, not only tickets from the Layer5 Cloud Help & Support modal. Both arrive with the samememberFormOnepayload shape, so no webhook-side change is needed - the note is so operators are not surprised by the new source.Context
Source change: layer5labs/meshery-extensions - routes Kanvas support submissions through Meshery Server per a maintainer ruling that all Kanvas communication flows through Meshery Server. The previous client-side path sent the signed-in user's name and email cross-origin to a third-party webhook.
Related: meshery/schemas#1148 (support operation schema divergence), meshery/meshery#21227 (host modal Submit-disable gap).
Filing rather than opening a PR directly because the source change lives in another repo; happy for this to be picked up as the companion docs change.