Skip to content

Change Topic Status

Moves one or more topics to a new status while a job is running. This is the op that writes the status. The workflow-palette op of the same name, Change Topic Status, does something different: it declares which transitions a category offers, and never moves a topic itself.

All the topics you name are verified before any of them is touched, so a bad mid or a topic sitting in the wrong status aborts the op with nothing changed. Once verification passes, topics are changed one at a time, and a failure halfway through leaves the earlier ones already moved.

before anything changes Topics every topic exists and matches Old Statuses no op fails, not one topic has been changed yes then, one topic at a time already in New Status? yes skipped, no log line no permission check unless bypassed status changed and logged

Fields

Topics

One or more topic mids, separated by commas. The form refuses to save this empty.

The value expands ${} placeholders. When the whole field is a single placeholder and the variable holds a list, the list is used as-is, so ${my_topics} works without any comma juggling. Mixing a list variable into a longer string fails instead, because a list has no sensible text form.

A placeholder that does not resolve is left in place as literal text. The op then goes looking for a topic whose mid is ${my_topics}, does not find one, and fails. An error message quoting a placeholder is the signal that the variable was never set.

Spaces around the commas are trimmed, but spaces at the very start and end of the field are not. A leading space becomes part of the first mid, the lookup misses, and the op fails saying that topic does not exist. A repeated mid is processed twice, which is harmless: the second pass sees the topic already in the target status and skips it.

Old Statuses

A guard, not a target. When set, every listed topic has to currently be in one of these statuses or the op fails before making any change. Leave it empty and any current status is accepted.

You can pick several statuses. Each entry is matched against both the status id and the status name, and the picker accepts values typed by hand for cases where the status arrives in a variable.

The trap: if none of the entries names a status that exists, the guard is dropped instead of failing. A misspelled status name here turns the safety check off and the op moves topics from anywhere. Pick the statuses from the list rather than typing them.

New Status

The status every listed topic ends up in. Required, and one value only.

The list itself holds statuses and nothing else, so a ${} placeholder has to be typed in by hand. The box keeps what you type, and the value is then accepted as a status id, a status name or a placeholder that resolves to either. A status that does not exist fails the op immediately, before the topic list is examined.

A topic already in this status is skipped: no permission check, no log line, no change event, and no back-to-origin restriction applied to it. Rules that re-run over the same set of topics go quiet on the second pass for this reason.

User

Who the change is attributed to, and whose permissions are checked. The form will not let you save this empty. The list covers active accounts including system ones, and the variables declared to hold a user.

This name lands on the topic timeline and travels with the change event, so notification rules that mention the acting user pick it up from here. If the op somehow reaches the job with no user at all, the job's own user is used, and clarive after that.

The permission check asks whether this user may move the topic from its current status to the new one under the category workflow. Being able to see the topic is not enough.

Touch parent topics to report change

Off by default. When on, each changed topic's direct parents get a modification bump, which shows up on their timeline and wakes up rules watching for topic changes.

Only one level up. Grandparents are not touched, and neither are children or siblings. An installation-wide setting can switch parent touching off altogether, in which case this checkbox does nothing.

Only back to original status

Off by default. When on, the topic is pinned after the move: the only onward transition offered to ordinary users is the one back to the status it came from. The pin clears by itself the moment the topic returns there.

Two kinds of user ignore the pin: root users, and anybody holding the permission to change a topic to any status. For them the full workflow stays visible.

The pin is written after the change lands, so it also overrides whatever the category workflow would have set for this transition on its own.

Bypass security?

Off by default. When on, the permission check is skipped and the change is made regardless of what the workflow allows for the user in User. The change is still recorded under that name.

Turn it on for statuses no human role is meant to reach by hand, such as an automation-only "deploying" status. Leave it off when the rule should respect the same workflow a person faces.

What the op leaves behind

Nothing is written into the stash under a name of your choosing unless you fill in the Return Key field on the op's options (see the rule palette). The return value is a small marker holding status: ok, which reads the same whether one topic moved or all of them were skipped. It is not a count and not a list. Setting Return Key to = merges that marker straight into the stash and overwrites any stash variable you keep called status.

Every topic that actually moves writes one line to the job log giving its mid, then the status it came from and the status it went to, each with its name and its id. Skipped topics write nothing, so a log with fewer lines than you have topics is normal.

A failure stops the step and puts the job into error, which starts rollback if the rule asked for one.

During a rollback pass this op runs again by default, with the same configuration, pushing the topics forward a second time. If the status change should only happen going forward, clear Run Rollback on the op's options, or wrap it in IF ROLLBACK.

The deprecated variant

The palette still carries an older op with the same name, struck through and labelled DEPRECATED. It offers four plain text boxes: Topics, Old status, New status and User. Only two of them do anything.

Topics behaves as described above. New status has to be the status id, because the older op does no lookup at all: type a status name and the op fails saying that status was not found. Old status is read off the form and then ignored, so it guards nothing. User is ignored as well, and the change is recorded with nobody attached to it.

It writes one log line per topic before each change, giving the topic title and the raw value you typed into New status. It runs no permission check and touches no parents, and it has no skip for topics already in the target status, so a re-run rewrites the same status again. Existing rules that use it keep working. Moving one over is a matter of retyping the values into the current form.

Combining with other ops

Feed the mids from Get topics that match conditions straight into Topics, or step over them with FOREACH CI when each topic needs different handling.

Pair it with Create a new topic, which returns the new mid, to open a topic and move it in one rule.

Guard it with IF var condition THEN when the move should only happen on certain environments or for certain categories, and follow it with Send a notification when the built-in status-change event is not the message you want.

The transitions this op may make for a non-bypassing user are the ones declared by Change Topic Status in the category workflow rule.

Examples

Close a set of topics carried in a stash variable, attributed to a system account, without asking the workflow for permission.

Topics       ${topics_to_close}
Old Statuses (empty)
New Status   Closed
User         clarive
Touch parent topics to report change   [x]
Only back to original status           [ ]
Bypass security?                       [x]

Move a single changeset forward only if it is where you expect it to be. With the guard set, a topic someone moved by hand in the meantime stops the job instead of being dragged forward.

Topics       ${changeset.mid}
Old Statuses In Progress, In Review
New Status   Ready to Deploy
User         ${job.username}
Bypass security?   [ ]

Park a topic in a holding status it can only leave by going back, so an operator cannot push it onward from the topic screen while the job is still working.

Topics       ${topic_mid}
New Status   Deploying
User         clarive
Only back to original status   [x]
Bypass security?               [x]