Skip to content

Remove Attached Files

Detaches files from a topic and deletes their stored contents. You either name the files one by one, or name an attachment field and clear everything in it.

The removal is not a soft one. The attachment record goes to the trash where an administrator can still see it, but the stored contents are removed from the file store at the same time, so the file is not downloadable again afterwards. There is no undo inside the rule and no rollback path.

The op works in any rule type. It does not need a running job.

Remove by Asset mids: file ids Fields: every file in them set of attachments can User write those fields? skipped when Bypass security? files removed, topic touched an empty list removes nothing and still reports success

Fields

Remove by

Two radio buttons that decide which of the next two fields you fill in, and which one the op reads at run time.

Asset mids names individual files. Fields names attachment fields and clears every file in them.

The choice is not only a display setting. Whichever field belongs to the option you did not pick is ignored when the op runs, even if a value is sitting in it from an earlier edit. Switching the radio and saving is enough to change the behaviour; you do not have to clear the other field.

Default is Asset mids.

Asset mids

The files to remove, given as file ids. Shown when Remove by is set to Asset mids.

Accepts one id, several ids separated by commas, or a ${var} holding a list. Spaces around the commas are trimmed, and empty entries are dropped, so a trailing comma is harmless.

An id that does not exist stops the rule. Which error you get depends on Bypass security?: ticked, the op gets as far as the file and reports that the file id was not found; unticked, the permission check runs first and reports the id as not being in a field you may write, which reads like a permissions problem and is not one. Either way, files already removed by an earlier run fail the second time, which matters for a rule that can be re-run.

A value that resolves to nothing removes nothing, reports success and still updates the topic's modification date. That is the silent case to watch for: a ${var} that never got set looks exactly like a successful removal.

Fields

The attachment fields to clear, given as field ids. Shown when Remove by is set to Fields.

Accepts one id, several separated by commas, or a ${var} holding a list. Every file currently attached to each listed field is removed.

A field id that is not an attachment field on that topic's category stops the rule, with an error that names the topic rather than the field that was wrong. A field that exists but holds no files removes nothing and reports success.

Topic mid

Which topic to act on. One topic per op; a comma-separated list is not accepted here.

${var} placeholders expand, which is how the op is normally used: ${topic_mid} inside a workflow rule, or ${mid} inside an event rule.

Required. Leaving it blank fails the op.

User

Who the removal is recorded as. ${var} placeholders expand.

The name you put here is used for the permission check below, for the author stamped on the topic's modification, and for working out who normally follows the topic so that a notification rule has a recipient list to start from.

Leave it blank and the removal is attributed to clarive, the system account. That account carries no roles as shipped, so a blank User with Bypass security? unticked fails the permission check rather than sailing through it. If you want a rule to remove files with no particular person behind it, tick Bypass security?; if you want the removal attributed to someone, name them.

Bypass security?

Unticked, the op checks that User holds write permission on the attachment fields involved, for the topic's current category and status. Removing by file id checks that each file sits in a field that user may write, and a failure names the file ids, the topic and the user. Removing by field id checks the fields themselves, and a failure names the user and the fields they were refused.

The check also fails when the topic's category has no attachment fields at all, which is the error you get from pointing the op at the wrong topic.

Ticked, none of that runs and the files are removed whatever the permissions say. Use it for housekeeping rules that run under no particular user, and leave it unticked for anything driven by a person clicking a button.

Default is unticked.

After the removal

The topic's modification date and author are updated, and its cached copy is dropped so the next view reflects the change.

Two kinds of event come out of this. Each file that goes deletes a resource, so any rule watching for resources being deleted sees one event per file. On top of that the op raises a single file-removal event for the topic, carrying the file names, the count, and the followers worked out from User. Notification rules hook onto that one; this op does not send anything itself.

The file-removal event is also what writes the entry on the topic's timeline. That entry is worded to name the field the files came out of, and this op never supplies a field name, so the line reads with a gap where the field should be. It is cosmetic, and it is not a sign the removal went wrong.

The op returns a status value, which is ok whenever it did not fail. Capturing it with a Return Key tells you nothing that the absence of an error had not already told you. Failures come back as errors that stop the rule, so wrap the op in TRY statement with CATCH statement when a missing file should not end the rule.

Nothing is undone on rollback.

Combining with other ops

Find the files first. Load the topic and read the attachment field off it, then feed the ids into Asset mids. SET VAR is enough when the list needs reshaping.

Guard the removal with IF var condition THEN so a rule that can run twice does not fail on the second pass with an id that no longer exists. Testing the list with NOT EMPTY also catches the silent case described above.

Pair it with Change Topic Status in a workflow rule when files should be cleared as part of moving a topic on, and with Send a notification when someone needs to be told.

Examples

Clear a whole attachment field when a topic moves past the stage that needed it.

Remove by          Fields
Fields             attach_evidence
Topic mid          ${topic_mid}
User               ${username}
Bypass security?   unticked

Remove a specific set of files collected earlier in the rule, with no person behind it.

Remove by          Asset mids
Asset mids         ${foo_stale_files}
Topic mid          ${topic_mid}
User               (blank)
Bypass security?   ticked

Clear two fields at once on a topic named by an event.

Remove by          Fields
Fields             attach_build_log, attach_test_report
Topic mid          ${mid}
User               ${username}
Bypass security?   unticked