Being able to edit the ticket text as the author or (for internal tickets) with the proper administrative rights is mandatory for us. This does not seem to be possible at the moment, although there are multiple reasons to provide some possibility for this:
- Internally created tickets can contain something faulty or some fault facts that need to be corrected in order to properly look at the problem at hand
- Tickets maybe “improperly” formulated. There need be a way to handle this without immediately “close/mark as spam” the ticket.
- Someone (even a client) can write a ticket and leave for a vacation on the next day. So someone else must be able to correct what might be wrong, or simply misleading - which is often the case.
It is one of the tasks of a project leader in our company to check internal requests and make changes where necessary. Reading through a multitude of notes is definetely not the way. For me this is for real discussion or follow up notes. But the ticket itseld has to be conclusive.
I suppose the reason for this might be the fact that Zammad is intended to be revision-proof. If an agent could just edit a ticket and e.g. permanently remove part(s) of it, Zammad would no longer be revision proof.
- use internal notes instead
- use the “split” function; it’ll allow you to edit the text of the new ticket. Then close the old ticket.
If you have a team of internal and external developers and you want to get to your goals then “revision proof” might be of no concern at all.
The system needs to be practical and elegant. If I cannot correct a typo, a mispronounciation, a factual error or undo what might later be considered as simply “inapropriate”, then we would make real distress out of simple and little everyday behaviour.
Before the real ticket is even processed, we would end up with a ticket and several comments with “corrections”, which takes more time to process because the ticket might not be everthing, without reading the first comments to be sure there wasn’t any additional information.
Besides that, we strongly disaprove of the so called revision-proof feature if all users are condemned to permanent storage of every word they’ve said. I tend to say that they even have (or should have) the unspoken right to insist that they are at least able to correct themselves - especially when it comes to a discussion like process or things that might be written down in moments of distress - which surely is exactly what a ticket system is all about, isn’t it. At least if I implement it as a trouble ticket system.
The “revision-proofnes” could be an option in the administration settings to OPTIONALLY prevent users or admins from editing their tickets. But in our opinion being able to edit a ticket is a must.
Besides. What exactly is revision-proof? As root, I’m able to manipulate everything I like anyways. But making my live harder by avoiding certain practical features that I need - just makes me consider another software - and makes therefore no sense at all.
P.S. I corrected this text after I initially wrote it because there was something which might have lead to a misunderstanding. Editing IS essential.
I’m with @martin.von.wittich a ticket system has to be revision-proof.
But i’m also with @nickbe - it’s a shame you can’t edit your typos.
Why not implement it kinda like Discourse or many other platforms?
Mark the note if it was edited and keep a history of changes in some form.
That way you’re able to edit your notes and the system is still-revision proof.
You might allow users to edit their notes. Just add a button labeled “History” which shows previous versions or the modifications made to them. By adding this, you’re still revision-proof. Jira for example does it in a similar way.
Important question to that: How would Zammad handle those updates?
Should they be “triggerble” ?
Because many users do sendout public notes as E-Mail to their client, thus the client won’t be able to see the changes and history in any way.
I’d really like to take a shortcut through all these considerations here.
If any of this would be the dealbreaking problem, then platforms like GitHub wouldn’t work at all. But they do and there I’m perfectly capable of editing whatever post of mine I like.
Even right here in this very community forum I can edit my own stuff if I need to. And if you look at the post below yours you can see the user uli-heller has just edited his comment twice. So I think Ive made my point.
You’d probably need some admin option where you could enable/disable editing of notes (and notes only - doesn’t make sense for mail).
This way customers who send out notes would at least have a choice.
Nevertheless there should be some kind of indicator if a note is edited OR created (to handle both actions differently).
@nickbe Dude really… taking a shortcut is not helping the community at all. You have to listen to other community members and take their opinion into consideration. You only made a point about other products having an edit function. Instead of telling everyone what you want try to be constructive and come up with a solution everyone can benefit from. Thank you.
Problem is: Our clients explicitly demand editable tickets and comments. At this point we could discuss all night long, but regretably this doesn’t change our problem. Without this (really simple feature) of being able to edit we cannot use Zammad - which we would wholeheartedly.
Can’t help you then. You’re in the wrong place.
Feel free to throw some money at the zammad devs (which they definitely deserve) and you won’t have to discuss with anyone except them.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.