New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance/rework message header of forwarded mails #3091
Comments
@mantas @MrGeneration - IIRC we agreed on sending the name instead of the email address to avoid leaking internal email addresses, right? What exactly was the use case/user story we were trying to cover? I got it mixed up. |
@thorsteneckel Yes, agent privacy was the main concern. User story for forwarding header or for omitting email address? |
How an agents address (or other internal mail) would end up in a forwarded email. |
Taken from system user profile |
While I agree that it's a potential privacy issue if it goes wrong, I also stated that it would be a good use case that you could enable manually:
I also pointed out that Zammad always has to ensure it's not sharing agent mail addresses:
So in short: I personally do agree with Martin and also can remember being asked about this by users. (e.g. during demos) I believe this would at least affect 60% of our user base that would want to do so. |
I'm 💯 on @martinseener use case as well What about a following option for forwarding:
I suppose the last one would be default Another related issue is email including when replying. It could follow this setting as well to avoid further confusion. |
I think it only should affect forwarding, as replying via UI does keep the recipients intact on replying to the article. I can also choose to remove a recipient if needed which then would also have to happen within the text field which might be troublesome and confusing for the user. I personally wouldn't like that. For forwarding, "include all email addresses" should only affect the article you're forwarding. This will also ensure that Zammad orientates on the way mail clients work. But that's my opinion |
It also keeps name and time. Yet some people do want full header included. If we're already adding a setting, I don't see why not extend it to this bit. It adds next-to-none hassle for us, no additional UX complexity, yet it may help someone.
Absolutely. It only affects the forwarding metadata line. No content of the article itself is touched. |
So from my PoV, if we could have the following, you would cover all possible use cases:
no 4 would be the "thunderbird" style of forwarding, though this is maybe too much for a ticket-systems default but i would at least default to 1. which would be okayish for most people including my use case but you can configure 1-4 - maybe per queue/email integration. then you can tune your workflow as much as possible. (or leave it as a global config which would also be fine i guess). |
So 1-3 would still "look" like zammad and No 4 would be in thunderbird style - maybe also quoted like shown in example above but with full header. That would be really nice to have and maybe not too hard to write (hopefully) |
Good point on CCd emails. Full header would be slightly more complicated. Right now we don't store raw email header in database. I how many people would actually use it vs being a nice option to have in settigns dropdown. @MrGeneration what's your opinion on "only customers" option to prevent agent emails from being shared? |
I think Option 1-3 would be sufficient then. Full header is rather "additional nice to have" but I also don't see a real benefit there. |
I agree, I'd only see options 1-3 as usefull options. No matter of the details of the option, Zammad should always not provide agents mail addresses. |
@martinseener 1-3 from your list or my list? You listed an additional option with CC while my list has customer-only option :) Personally I'd rather just include CC'ed emails whenever any email is included. @MrGeneration do I read it correctly that we shouldn't have an option to forward agent emails at all? I could see that being an issue with agent-as-a-customer workflow. |
Yeah basically your list @mantas . So no agents addresses but To/CC addresses from customers or other people. |
No, what I meant: |
That's what I tried to say - that article could be forwarded, but agent email wouldn't be forward and there would be no option to allow that :) How would it work in agent-as-a-customer situation? Would it treat that agent as customer-by-sender-type (thus including email) or agent-by-role (thus overriding email)? |
My bad. In my opinion Zammad wouldn't handle the agent being customer as customer. |
I'm not sure if it's already merged, but I remember seeing something like that in our private work-in-progress branches recently... IIRC the use case was that in big companies one department may be a customer of another department. |
Zammad by default knows all email addresses with the permission |
@MrGeneration #2815 is a predecessor/duplicate of this, right? |
@thorsteneckel looks like yes |
Can I please get a list of scenarios/use cases for each of the possible options and an estimation on how many percentage of our user base would use it? |
So I've been talking with Mantas internally and this is basically what came out of that. I have no proove of those numbers below whatsoever - if we'd need real numbers, we'd need to start a survey. I also agree on Issue 2815 - this is a duplicate of it. As this issue however has more input, I'd suggest to close issue 2815 or switch over as soon as we have pinned down how we proceed to keep the issue short and hopefully not cause confusion. Okay so.... I hope the following does help better to understand the scopes. RepliesWhen replying to a mail -no matter if in Zammad or not- where your mail client does quote the earlier text, it will add a short quote text e.g. like This is useful if you quote several texts from maybe even several mails (which Zammad does support). It always does use the sender of the article, so basically the display name of the FROM. A mail reply does always contain the original sender. In fact when hitting reply, your recipient will always be the sender of the mail you reply to. ForwardsForwards -at least usually- are supposed to send information to another third party. No matter if that's another Zammad system or an individual.
During the process of forwarding (because TO and CC are not pre filled), you will loose the information who that email originated from. This will allow the recipient to get in direct touch with John if needed. If you simply reply to an forwarded message, you'll answer to the forwarding sender which in this case would be Zammad and the wrong recipient. This causes agents either
This is why Zammad should allow administrators to provide these information during forwards. In fact I think that this should become the default option for new instances. On existing instances I believe that this by default should be disabled. Now to the use cases (now it gets complicated). 1. (current default) quote displayname onlyCurrently when forwarding a mail from Zammad to a third party, Zammad will use Personally I think there's a use case where you want Zammad to do exactly that:
Personally I think this use case is valid for ~20% of our user base. 2. quote displayname and FROM email address onlyThis will provide only the senders mail address to be provided. I Personally think that this use case does affect less than 10% of our userbase. I honestly can't think of a use case (except the very thin one above) where you'd want half baked information 3. (default for new instances) quote displayname and all recipients of original mailEspecially if using a lot of CC's to inform more than one person, it'd be better to provide your forward recipient with all mail addresses because
With this step we will get close on the way other mail clients do behave.
In the end Zammad is supposed to help the agents, not to provide more work load ;x I think that this will affect 70% and more of the user base. I think behaviour 1 and 3 are the most important ways on how Zammad does work. Mantas pointed out that it might be confusing to simply leave out the agents mail address and thus suggested to user the groups mail address. I am however worried that this might lead to bug reports because Zammad might choose a mail address the user thinks is the wrong one. The other possibility apart from removing agents or to use a mail address of Zammad would be to use |
I've read through and I would agree to all of it! Thanks for this great writing. I would love to see 3 coming into Zammad. 2. is maybe a "nice to have" if it doesn't add too much of a hassle as I also see it as a method with a very small user base. For the very last part, in my opinion you should rather forward mails as Agents Name + Groups Mail like For everything else you wrote -> 💯 on your side :) Hope to see it soon, we can use it finally and save some work time. |
Thanks a ton guys @martinseener @MrGeneration and @mantas ❤️ I'm convinced and totally on your side. To follow our philosophy we will skip option 1 and 2 completely and replace the current default behaviour (2) with 3 for all instances. IIRC this was the original intend of the previous PR #3014 . Now that we specified the requirements and use cases/user stories in more detail I can see clearer. Thanks! Depending of the size of the change I'll consider having it backported to 3.4 as well. Looking forward to review the MR! |
Any preferences on exact style? I was clicking around several email clients and I'm warming up to @martinseener 's proposed When more details are added, it's much easier to read than the human reply style. Even if we don't store full headers, we could imitate this style with the details we got. @thorsteneckel which approach do you prefer for hiding agent emails? Printing name only or |
@mantas I agree. When adding more informations, something that is readable and familiar (Thunderbird) is maybe a good option. |
Apple mails uses (basically) the same format:
👍 |
Can someone please add a short notice on how you proceed internally with this ticket now? Is there any roadmap or rough plan on when this will be available? |
We're actively working on it. I'll make sure it doesn't get stuck in limbo :) |
Hi @martinseener - it's done thanks to @mantas ! The release will be available in about 30 minutes from now. You can just update your Zammad via the system package manager and should be ready to go. Looking forward to your feedback 🚀 |
JFI: I'll accidentely hit "update" on your paid instance on the hosted setup later on (~19:00 - 20:00 ). So tomorrow will be a better day. 🙌 |
@thorsteneckel @mantas @MrGeneration thanks alot for that. I just upgraded to 3.4.0-1594825410.4cacfa4b via my system manager (also to ES 7.8). When now forwarding, the full header is visible there. Nice!One question regarding attachments though. I don't see an option to forward the mail including the attachment if there is one. Is there a way to also forward them (by default)? Maybe an additional ticket? |
Zammad should always forward with attachments. |
@MrGeneration i'm sorry. I think I did a mistake. |
Infos:
* Ticket-ID: #1070545, #1077139Expected behavior:
When forwarding a ticket, I would expect that the original FROM header (or at least the original FROM email address who sent the mail to zammad) is included in the forwarded email (like every mail client does it), so the people/other ticket systems users can see the original author and directly answer to them.
I expect Zammad to allow forwarding of the original sender email address at least in the forwarding header message after the name. I see that this might make troubles to some scenarios but in other scenarios this behaviour is strictly needed, so i expect this to be configurable in the config or better in the UI directly (in email integration for example, globally or per integration)
Actual behavior:
Currently only a name and date are sent but the person the ticket has been forwarded to, cannot answer him as his FROM email address is missing.
Steps to reproduce the behavior:
Forward an email/ticket from latest Zammad
Yes I'm sure this is a bug and no feature request or a general question.
The text was updated successfully, but these errors were encountered: