type of this job
reason we don't use job type enum is to avoid circular dependecy (job already refers here)
also since default jobType is 0 which happens to be the Normal type that is the only possible
one (issue referring to source normal job), before the advent of on-demand instances starting
from on-demand jobs (normal referring to source ad hoc job).
Value depends on ResourceType value
USER, JOB, DOCUMENT, JOB_ROLE:
id of resource
STEP (includes step groups):
jobBasedStepId of resource
FIELD:
comma separated jobBasedStepId of
parent step and fieldId
ALL_USERS_IN_JOB:
empty
OTHER:
empty
This must be set to true to know you can handle messages containing
documents which are not yet uploaded but are “pending” and hopefully
will be sent soon.
default
false
2
beforeSeqId
bool
If this is true, then client is requesting messages from _before_ the
sequence id, not from _after_ it.
default
false
3
limit
i32
This is the number of messages to be retrieved at a time.
Any value less than one is considered to be the maximum allowed.
The maximum allowed is defined on the server. At present, it is 10K.
default
0
Struct: Message
Key
Field
Type
Description
Requiredness
Default value
1
id
string
default
2
jobId
string
default
3
seqId
i64
default
4
clientCreatedAt
i64
timestamp when message was created on client - in seconds
Send documents with isPending = true & empty ids to reserve documentIds;
these will be returned in the order they were passed in, but with the ID
filled in. If the mimeType and size are provided, the receiving end can be
clever about its UI to display progress.
On Get, messages containing any pending documents will only be returned
if the option canHandlePendingDocuments is set to true.
default
51
updatedSeqId
i64
If this is an update to a previous message that had a pending document,
this is a reference to the earlier message that is now updated. If several
modifications happen to same user-facing message this will still point to
the original seqId (the anchoring location) and not subsequent ones.
optional
200
deviceId
string
For Mesh
optional
201
deviceSeqId
i64
optional
Structured body contains a rich message body of the following format:
To display messages as a client, the client should take the following steps:
Detect all sequences in the template matching \{\{([^}]+\}\}, anything inside double braces {{}}
Within those sequences, the text should correspond to an entry in the resourceLocator
Use the ResourceType of the entry to determine object type
If the Label field is populated, use the label as the display name. If not,
use the Id and Type fields to fetch the appropriate object and label
Sending a strutured message
In order to send structured data, follow the format above when constructing a message struct to
send to the server. The server will prioritize the StructuredBody field over the body field when
present. In order to escape "{{" and "}}" replace with "\{{" and "\}}" respectively. The clients
will be responsible for unescaping. Escape format is defined for consistency across clients.