Training sessions and recordings
Send a Training topic suggestion to support
/a/Training_suggestTopic
Send a Training topic suggestion to support
When to use this endpoint
Send a proposed training subject and details from the Training Home suggestion dialog. The endpoint creates a tenant support-ticket record and sends the suggestion with authenticated account/user context; it does not grant support permission to view or edit the account.
Authentication and permissions
Authenticate with signed API-key fields or a logged-in CRM session. Every Training handler requires login; there is no additional page, role, department, or tenant feature-flag check. CRM2 exposes Training to authenticated users.
Webinars and session IDs belong to a shared global catalogue. Interests and provider registrations are scoped to the authenticated tenant and user even though they are stored globally. Client-supplied tenant/user IDs do not select another person’s bookings or progress.
This action writes the authenticated tenant’s support ticket and reads the authenticated user’s name/email. The subject/description do not select a different recipient, account identity or support-access permission.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
subject | String | Yes | String-converted and trimmed. Must contain 1–100 bytes after trimming (strlen, not Unicode character count). Missing/blank/too-long values fail before login. |
description | String | Yes | String-converted and trimmed. Must contain 1–65535 bytes after trimming. Multibyte text consumes multiple bytes. Stored as supplied text; mail body HTML-escapes it. |
Example request
$result = FM_api('Training_suggestTopic', [
'subject' => 'Planning recurring jobs',
'description' => 'Please cover preparing a recurring schedule and reviewing the generated jobs.',
]);Example response
{
"ok": 1,
"id": 1042
}id is the positive new tenant support-ticket ID, not a webinar/session/provider-registration ID. The normal envelope follows a positive mail-service acknowledgement with a queue ID and a successful sent-status write; it does not prove inbox delivery or return that queue ID.
After ticket creation, failed/uncertain mail, identity lookup or sent-status persistence retains ok/id and adds saved=1 plus warning. For example, {"ok":1,"id":1042,"saved":1,"warning":"Training suggestion saved, but email was not acknowledged. Do not submit it again; contact support with ticket ID 1042."}. Do not treat this as a replayable creation error.
Errors and unusual responses
| Response | Condition |
|---|---|
{"error":"not logged in"} | No authenticated tenant context is available. Invalid signed credentials can be rejected by the dispatcher before the handler runs. |
{"error":"missing or invalid parameter: subject"} | Missing/blank trimmed subject or more than 100 bytes; guard precedes login. |
{"error":"missing or invalid parameter: description"} | Missing/blank trimmed description or more than 65535 bytes; guard precedes login. |
{"error":"Unable to save Training suggestion. No email was sent."} | The initial ticket insert did not produce a positive ID. The handler stops before preparing or sending mail. |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- Inserts support_tickets with topic=Training, subject/description, Unix creation time, authenticated user_id, status=0 and permission_access=0/permission_edit=0. The insert must produce a positive ticket ID before any mail is attempted. Neither permission flag comes from submitted fields.
- Marks status=1 only after mail replies with a strict positive ok value and a positive numeric global_id/id, without an error. Failed or malformed acknowledgements leave the saved ticket pending and return a warning. If mail was acknowledged but status persistence fails, the warning explicitly reports that distinction; the mail is not automatically resent.
- Mail uses the configured support recipient (fallback support@fieldmotion.com) and the authenticated user’s email when present. Empty recipients are filtered; the handler does not deduplicate them. The user’s email is also used as reply-to.
- The body includes authenticated client/user IDs, company/user names and user email, then escaped subject/details with line breaks. Subject metadata is prefixed “Training topic suggestion: ”. Tenant/user details are server lookups rather than trusted request fields.
- No local length-based pagination, rate limit, duplicate-submission token or catalogue publication occurs. Repeating an accepted request attempts to create another ticket and another mail.
- No Core_log row, tenant deletion log, provider subscription or training-progress update is produced.
Side effects
- Creates a tenant support ticket, calls Core_mail for support and user recipients, then updates ticket status. The mail helper dispatches to the mail service and adds tracing context; test requests use private no-send mode. These steps are not one transaction.
See it in Fieldmotion
CRM1
No direct CRM1 caller for Training_suggestTopic was found. The implemented screen is CRM2 Training; no direct mobile-app or m-service caller was found for these CRM routes.
CRM2
Training Home → Suggest a topic → Send suggestion submits Training_suggestTopic after browser form validation. CRM2 displays saved/partial-failure warnings and closes the dialog without announcing “sent” or repeating the request. Ordinary acknowledged success reports “Training suggestion sent.”; use mail evidence when diagnosing inbox delivery.
Related endpoints
Training_list: existing published training catalogue.Training_get: details of a specific published session.