Assign SLA configuration to topics
Attaches one SLA Configuration to a list of topics, overriding whatever the topics inherited from their category. Use it when the SLA depends on something the category cannot know: a project going live, a severity field, an incident being escalated.
The op only records which configuration applies. It does not measure anything and does not set a colour. A background evaluator compares each topic's time in its current status against the thresholds and writes the green, yellow or red state later, so nothing visibly changes at the moment this op runs.
Fields¶
Mids¶
Which topics to update. Required, and the grey hint in the empty field shows the two shapes it takes.
Accepts a comma-separated list of mids, a ${var} placeholder holding a list, or a
mixture of the two. All of these work:
topic-101,topic-102
${topic_mid}
${changeset_mids}
${release_mid},topic-900
Spaces around the commas are trimmed. Blank entries in the middle of a list are skipped without complaint, so a trailing comma is harmless.
Leave it empty, or hand it a variable that resolves to nothing, and the op fails with a missing parameter error and stops the rule. That is the only check made on the list itself.
A mid that does not name a real topic is a different story: the write finds nothing, changes nothing, and says nothing. There is no per-topic check and no warning. Typos, stale mids and mids from a deleted category all pass through silently.
SLA Configuration¶
Which configuration to attach. Required, and one only. Pick an
SLA Configuration resource from the list, or type a ${var}
placeholder for one.
A typed value is matched against the resource's identifier, its name and its short name, so
${sla_name} holding Gold support resolves as long as a configuration carries that name. A
placeholder that resolves to a list is cut down to its first entry with no warning.
If it resolves to nothing the op fails before touching any topic, so a bad configuration value leaves the topics exactly as they were. The mid list is only processed once the configuration has been found.
What it writes¶
Every listed topic gets the configuration recorded in two places at once: the topic's own setting and the topic's copy of its category settings. The category resource itself is not touched, and other topics in it keep what they had.
There is no comparison and no skip. A topic that already had this same configuration is written again, a topic that had a different one loses it, and a topic that was following its category stops following it from then on.
Each updated topic is dropped from the topic cache, so the next read rebuilds it and the new configuration is there when you open the topic or a board.
Set Return Key on the op's Options tab and the variable receives a record with an assigned
count. Read that count carefully. It is the number of entries the Mids field split into, taken
before a single topic was looked at. Blank entries that were skipped are counted, mids that name
nothing are counted, and the number stays high when every mid in the list was wrong.
Nothing is written to the job log by the op itself. To see what happened, print the mid list with LOG Message before this op runs.
Rollback¶
The op keeps no record of the previous configuration, so there is nothing to put back.
On a rollback pass it runs again with the same settings and reassigns the same
configuration, which is almost never what you want. Untick Run Rollback on the op's Options tab
unless you have a reason to keep it, or wrap it in IF ROLLBACK to
control which pass it runs on.
To undo an assignment, run the op again with the configuration the topics should fall back to. There is no way from this op to clear the assignment and return a topic to its category default.
When the state does not change¶
The evaluator never picks up a topic whose current status is a final or closed one, nor a topic in a status marked inactive. Assigning a configuration to a closed topic is accepted and then sits there doing nothing until the topic is edited or moved.
It also skips any status that has no threshold row in the configuration and no default row. The topic keeps whatever state it last had, which can look like a stuck colour. Give the configuration a default row unless you deliberately want some statuses unmonitored.
A configuration with Only for Projects filled in narrows what the evaluator looks at. Topics
outside those projects carry the assignment and are passed over anyway, with nothing said. That is
the most common reason this op appears to have done nothing at all.
Evaluation runs on a timer, by default every 60 seconds across 50 topics at a time, so expect the colour a cycle or two after the op ran rather than immediately. Editing the topic is quicker: any save recalculates its state on the spot.
Combining with other ops¶
Collect the topics first. Get topics that matches conditions
with Fields set to mid gives you a list to pass straight in, and
Load Related Topic with Mids only? ticked does the same
for the children of a release.
Gate the assignment on something real with IF var condition THEN, for instance only pushing the strict configuration when a severity field says so.
Pair it with Change Topic Status when an escalation both moves the topic and tightens its SLA. Put the transition first: it restarts the clock and drops the topic back to green, so a configuration assigned before it is measured from the new status anyway.
Examples¶
Put every changeset in a release onto the release-grade configuration. The mid list comes from an earlier op.
Mids ${changeset_mids}
SLA Configuration Release SLA
Return Key sla_assigned
Escalate the single topic that triggered the rule, nested under a condition op so it only fires on high severity.
Mids ${topic_mid}
SLA Configuration Critical incident SLA
Apply one configuration to a short fixed list during a migration rule.
Mids topic-101,topic-102,topic-103
SLA Configuration ${target_sla}