We had one of our agents accidentally attach a document with proprietary information in a response to a customer’s ticket. I found this ( Deleting Records — Zammad System Documentation documentation ) but it doesn’t have anything specific to articles.
I’ve seen other topics like this one ( Extend Article Deletion Window with Admin-Controlled Settings ) that mention a time limit on deleting articles, but we are way past that at this point. It took an administrator finding the mistake before we noticed what had happened, and it was almost 2 days after the response.
Is there a way to delete the articles either via the command line or in the web-based interface at this point for us? Or, just the attachment?
I just wanted to follow up on this to see if there is any way to delete this attachment. I tried to see if I could just do it via the command line, but figured out in the documentation that the default storage is the database and I do not know how to safely delete an attachment from the database.
I can see two records for the attachment in the stores table but I’m not sure that this is the record that holds the actual file or if deleting directly would result in other issues. If anyone knows how I can delete it directly, I’d really appreciate it.
Another method I tried was directly through the API. I saw in the attachments controller it looked like there might be some way to remove it via the API.
Using Postman, I can show the attachment using the following endpoint:
GET http://{{zammadDomain}}/api/v1/attachments/:attachmentId
However, when I attempt to delete the attachment using the endpoint:
I’m not sure how to proceed, and having this document in this system is a continued risk. Not even other agents should be able to see this, but they can now find it simply by looking at this ticket.
Please, any guidance would be greatly appreciated!
TL;DR: (backup first)
sudo -u your-zammad-admin zammad run rails c
article = Ticket::Article.find(12345) #find your article
article.attachments.pluck(:id, :filename) #look at all the attachments before deletion
article.attachments.each(&:destroy)
SearchIndexBackend.update_index(article.ticket)
exit
Zammad has no official support for removing individual articles or attachments from tickets. You can remove the entire ticket and any other tickets in which the same attachment is referenced. If you do that, and no more ticket articles reference that attachment, it will be removed too.
Simply (only) deleting the file from storage will cause issues for Zammad, as it holds metadata about this file in the database too (location, checksum, name, links to other articles, etc etc). You can however attempt to replace the file contents with other data and update all the relevant database records too with that new metadata. I successfully did that a long time ago on an older Zammad version.
The Zammad folks will (rightfully) shout at you (and me) that you should not do this under any cicrumstance, and that it is potentially very dangerous for your installation, because you’ll likely cause more issues and possibly cause irreversible data corruption in your install, and breaking your Zammad instance. You’re on your own if you decide to do this.
@dvanzuijlekom@MrGeneration thank you for your follow-ups. I’ve seen the warnings in this forum and I think also in the documentation itself not to operate on the database directly. Honestly, part of me thought the only way to get a response on my question here would be to suggest something “so stupid” - seems like it worked haha. I never intended to do that unless I was given clear instruction on how to do it without risk.
Thank you for explaining that the attachment will be removed if we remove all references to it via the tickets. I hadn’t come across that information anywhere else. I guess when we are done handling the ticket with the user we will just have to delete it and I will double-check the database to make sure it’s gone.
@DD4PK thanks for this as well. I had tried to use the rails console to see if I could find a way to access attachments but I couldn’t get even get to the part of getting an article. Now that I know Ticket::Article is the way to do this, it may come in hand in the future.