rt-munge-attachments(8)

πŸ’– rt-munge-attachments β€” bestie edition πŸ’–

okay so real quick, this is rt-munge-attachments from the Request Tracker Reference (that's the manual name, it's giving rt-munge-attachments(8), section 8, system admin tools 🫢). Buckle up.


✨ NAME ✨

rt-munge-attachments β€” literally just removes or replaces strings inside attachment records. that's it, that's the whole gig πŸ’…


🌸 SYNOPSIS 🌸

rt-munge-attachments --search="user1@example.com" --replace="removed-user@example.com"

look at her go. one line, two flags, vibes immaculate ✨


πŸ¦‹ DESCRIPTION πŸ¦‹

okay so first thing you need to know: in RT, "attachments" are not just file attachments. they contain all correspondence on tickets. like everything. the whole conversation. no cap.

normally RT doesn't touch attachments once they're created β€” they're frozen, they're iconic, they're done. but this script? this script is the exception. it gives you a way to change or remove personalized data like email addresses that might be chilling in the headers or the bodies of RT attachment records. why would you want that? so admins can comply with GDPR regulations while still keeping the ticket histories around with all the remaining non-personal info intact. yes, you get to keep the receipts, just with the personal bits yeeted out πŸ™ˆ

and here's the important part, bestie, don't skip this:

a transaction is recorded when this script modifies content. so there's a record that something was changed on the ticket. but β€” and this is the key β€” the details of the change are not recorded, because the values would likely contain the exact personal information the script was run to remove. makes sense tbh. can't log what you're deleting. that's a paradox fr fr πŸ’€

⚠️ big one: if modifying ticket history violates your audit policies, admins should not use this script. periodt. no exceptions. if your org says history is untouchable, then it's untouchable and this script stays in the drafts folder 😭

πŸ’… OPTIONS πŸ’…

  • --search=SEARCH β€” hand her a string and she'll go search the header and content columns in the attachments table. if a match is found, the content gets removed unless you also hand her a replacement. so like, search alone = delete energy, search + replace = glow-up energy ✨
  • --replace=REPLACEMENT β€” your replacement string. this is what gets swapped in for whatever --search matched. the makeover πŸ’–
  • --tickets=1,2,3 β€” limits attachments to the tickets you list. now listen, this one has lore: if you don't specify tickets or transactions, RT pre-filters attachments by the search string using SQL, and that pre-filter might bypass attachments whose contents are encoded (like base64). use this option to prevent that pre-filter behavior. it's giving loophole-closer πŸ•΅οΈβ™€οΈ
  • --transactions=123,456,7 β€” limits attachments to the specified transactions. if you specify this, the default pre-filtering gets prevented too. and yes, she plays nice β€” this option can work alongside the --tickets flag. besties supporting besties 🀝
  • --skip-headers β€” by default, headers are also munged. wanna disable munging of headers? set --skip-headers. hands off the headers, periodt πŸ™…β™€οΈ
  • --skip-content β€” by default, transaction content is munged. wanna disable munging of content? set --skip-content. content stays exactly as she is, untouched, pristine, main character energy πŸ‘‘

🧚 tiny reminder: these two skip flags are your off-switches. if you came here to munge everything, don't set them. if you want to protect one half, flip the matching switch. iykyk.

that's the whole page bestie, go forth and munge responsibly 🌈

β€” sign-off from your girl: this manual page ships with perl v5.40.1, dated 2026-06-21, and it's part of the Request Tracker Reference set. slay, bye πŸ’œπŸŽ€

πŸ“¦ where this page comes from