Change Topic Status

Declares a transition out of wherever the topic is now. There are no conditions on the op itself, so whatever reaches it gets the transition. Put the conditions around it with the workflow IF ops, or use Change Topic Status If Matches, which carries the test and the transition together.

The op is worth choosing when the rule above it has already decided, and the transition should apply from the topic's current status whatever that status happens to be. Two or three of these nested under IF Role IS read better than the same conditions repeated on every transition.

There is a second op with the same name in the job palette. Change Topic Status moves a named topic while a job is running. This one declares what the Change Status menu offers, and changes nothing by itself.

Fields

The form holds a single group, SET TOPIC STATUS TO....

To Status

Where the topic lands. The form will not let you leave it blank, and a saved rule that has lost the field entirely, through a hand edit or an import, stops the workflow with a missing-configuration error. Each entry produces its own transition, so two To Statuses put two entries in the Change Status menu.

You can type a value instead of picking one from the list, and ${var} placeholders in a typed value are expanded before the transition is built. The picker stores status identifiers, and a status identifier the topic's category does not carry is discarded after the rule finishes, with nothing logged. That is the usual reason a transition that looks correct never shows up.

Deployment Type

What taking the transition does.

Deployment Type	Effect
No Job	the status changes in place, no job is created, the transition appears in the Change Status menu
Promote	the transition appears under Promote and starts a deployment job
Demote	the transition appears under Demote and starts a backout job
Static	never offered in the Change Status menu, reserved for the deployment path

A Deployable status reached with Promote or Demote is held back from the Change Status menu, since it is meant to be reached through the Promote and Demote menus. It reappears there in two cases: when some transition anywhere in the rule reaches that same status with No Job, or for a user holding the Change topic status logically (no deployment) permission on the category. A Static target is removed from the Change Status menu in every case.

Picking anything other than No Job has a second effect that the label does not suggest. The op narrows its origin statuses down to the selection made by the last IF From Status IS the rule passed through. Nested inside that gate, the narrowing changes nothing, because the gate already made the same choice. The selection stays in force after the gate's block ends, though, so a Promote or Demote op written after a status gate rather than inside it is narrowed by that gate too, and produces no transition at all when the topic's status falls outside the gate's list. With No Job there is no narrowing.

Only back to original status

Unchecked by default. Once a topic lands in one of the To Status entries through this op, the only transition offered from there is the one back to the status it arrived from. The lock clears the moment the topic goes back. Root users, and users holding the Change a topic to any available status in its category permission, are never restricted by it.

The lock is applied by reading the saved rule when the status changes and checking whether any checked transition op in it lists the status the topic has moved to. For this op the status it moved from is not part of that check, and neither is the route the topic took, so a move made by a job or by a root user sets the lock as readily as one made from the Change Status menu. The check reads the To Status list as it was typed, so a target written as a variable never matches and never locks, even though the transition itself works.

Who gets the transition

There is no Roles field. The transition is granted to every role the user holds on the topic, which means anyone who can open the topic sees it. That is the main difference from Change Topic Status If Matches, and the reason this op is normally nested inside IF Role IS.

A user holding no roles on the topic produces no transitions at all, so a missing menu entry can come from project security rather than from the rule.

Where the transition starts

On a real topic, from the status the topic is in. The op never needs a From Status field for that.

When Clarive collects the complete map of transitions for a category, as the Promote and Demote menus and the category workflow view do, there is no current status, and the op emits one transition from every status in the category. A single unguarded op therefore draws a transition from everywhere to the target. That is only what the listing shows. The menu a user sees still starts from the topic's real status.

What the rule produces

Each transition op appends to the workflow list in the stash. Nothing is replaced, so several transition ops accumulate and identical transitions collapse into one menu entry.

Transitions whose origin or target is not in the category's status list are dropped once the rule has run. A category with no statuses fails the workflow with an error instead of returning an empty menu. A rule error reaches the topic screen as a workflow error, but the Promote and Demote menus and the category workflow view swallow it and show an empty list. A workflow rule that has been deactivated is never run, and every transition disappears at once.

Combining with other ops

IF Role IS, IF From Status IS and IF Project IS are the natural wrappers. Each holds nested ops that only apply when its test passes, and this op is the thing you nest.

For anything those three do not cover, such as a topic field or a value another op wrote, wrap the op in IF var condition THEN.

Change Topic Status If Matches replaces the whole arrangement when the conditions belong to one transition rather than a group.

To move a topic while a job runs, use Change Topic Status from the job palette instead.

Examples

A plain approval step, gated by role.

IF Role IS   approver
  Change Topic Status
    To Status         Approved
    Deployment Type   No Job

A promotion that locks the topic until it is demoted back, sitting under a status gate so it only appears from the right origin.

IF From Status IS   Approved
  Change Topic Status
    To Status                      In PROD
    Deployment Type                Promote
    Only back to original status   checked

Two exits from the same gate, offered side by side in the menu.

IF Role IS   reviewer
  Change Topic Status
    To Status         Rejected, Needs Work
    Deployment Type   No Job