Skip to content

Topic Delete

Removes topics from inside a running job. The removal is permanent: the topic, its links to other topics and resources, and its time-tracking entries all go, and there is no undelete. If what you actually want is for the topic to stop showing up in boards and queries, move it to a closed status with Change Topic Status instead.

The op works through the list one topic at a time and keeps going after a failure. Topics that no longer exist are noted and skipped. Topics it could not delete are remembered, and the op fails at the very end with all of them listed, by which point the topics before them have already gone.

Topics for each topic, does it exist? no logged and skipped yes may this user delete it right now? topic removed for good no error remembered op fails at the end

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 it stands, which is the usual way to delete the output of an earlier query. Mixing a list variable into a longer string fails, because a list has no text form.

A placeholder that does not resolve is left in place as literal text. The op looks for a topic whose mid is ${my_var}, finds nothing, writes a line saying that topic does not exist, and carries on. So a mistyped variable name here gives you a clean run that deletes nothing.

Spaces around the commas are trimmed. Space at the very start or end of the whole field is not, and a mid carrying a stray space is reported as a topic that does not exist. A mid listed twice is deleted once: the second visit finds it gone and skips it.

User

The user the deletion is attributed to, and whose permission is checked. The form will not save without one.

The drop-down offers active accounts, including system accounts, and every global variable that holds a user, listed as ${name}. You can also type a value the list does not contain and it is kept as typed, which is how you point the field at a variable the drop-down never learned about.

There is no bypass on this form. The permission is checked on every topic, every time, against the right to delete topics in that topic's category, bounded by the topic's status and its project security. Pick an account that holds the delete permission across all the categories the list can contain, otherwise the op deletes the topics it can and fails on the rest.

Change Topic Status and Create a new topic fall back to the user the job runs as when this field is empty. This op does not. It falls back to clarive.

Topics the op refuses to delete

A topic sitting in the changeset of a job that is waiting, running, paused, trapped, skipping or retrying cannot be deleted. That includes the job running this very rule, so a rule cannot delete its own changesets while it still holds them. The message you get back says only that the topics are in active jobs. It does not name them, so you have to go and look for the job yourself.

Permission failures land in the same bucket. Both kinds are remembered rather than raised at once, and both surface together when the op fails at the end of the list.

Logging, failure and rollback

One line per topic: deleted, does not exist, or error. The missing and deleted lines are plain information, so a run that deletes nothing at all still reads as a normal run. Only the closing failure, which repeats every collected error, marks the step as failed.

Every removal raises a topic delete event under the user you picked, so notifications set up for deleted topics go out to the people watching that topic while the job is still running. A rule that tidies up scratch topics can therefore mail people about topics they never saw.

When the op fails, the step stops and the job goes into error, which starts rollback if the rule asked for one. Deleted topics are not restored by rollback. Nothing restores them.

By default this op runs again during a rollback pass. The second run finds the topics already gone and writes that they do not exist, so it is harmless, though it adds noise to the log. Clear Run Rollback on the op's Options tab to stop that, which is one of the settings described in Rule Palette.

Combining with other ops

Get topics that matches conditions is the natural source for Topics: build the list by category and status, then hand it straight over. Check the list is not empty with IF var condition THEN first, because an empty list is a silent no-op here.

Pair it with Create a new topic to undo scratch topics a rule made earlier, driving the deletion from the mid captured in that op's Return Key and guarding it with IF ROLLBACK.

When you want the topics kept but out of the way, use Change Topic Status and a terminal status instead.

Examples

Delete the child topics collected earlier in the rule, as a system account.

Topics   ${child_topics}
User     clarive

Delete one topic named by a resource reference. The mid, not the title, is what goes in the field.

Topics   ${scratch_topic.mid}
User     clarive