我激活了警报中的所有警报（成员团队或小组除外），测试工作电子邮件并设置一个主题通知所有人......
（已编辑）
然后通过门户网站或电子邮件接受用户的票证请求..
所以然后发送电子邮件并发送到配置好的。 使用 cc 电子邮件，那么我们有： 一个 dest email1@domain ，一个 cc colab1@domain
当 osticket 打开票证时，cheff 和警报中配置的所有 involucrate 都会收到有关新票证的电子邮件通知，但合作者不会
协作者仅在打开的故障单上发生第二个威胁/注释/事件时（例如，更改状态、做笔记或让响应）由任何 involucrate 收到通知
要让合作者得到通知，我必须激活“所有成员”，这是无稽之谈，我只希望自第一次进入票威胁以来，总括者收到消息。
提前致谢
mckaygerhard
所有22条评论
我发现以前报告为#1130 的相关问题但此时仍未实施
我必须在哪里编辑才能做到这一点？
mckaygerhard
于 2015-08-31
尽管如此，无论如何，如果出现在 1.10 品牌中，1.10 仍然不稳定，我无法在组织中建议在生产中使用...
差不多一年了，当代理商为用户打开门票时，我仍然为 1.9 品牌为上帝和外星人的爱制作了
mckaygerhard
于 2016-05-28
@mckaygerhard我们不发送初始电子邮件，因为协作者已经包含在用于创建票证的电子邮件中。 为什么他们会收到第二封包含相同信息的电子邮件？
greezybacon
于 2016-06-25
因为那些 dest 收到了正常的电子邮件事件和 ostiket 通知
如果我可以从界面上制作一张票，并在第一步中添加 colaboratos，则将发送的邮件将发送给所有相关人员（作者、客户和合作者）
由于所涉及的人确实收到了一封正常的电子邮件，然后那些人回复了正常的电子邮件，所有的威胁都发生在 thiket 威胁之外！ 支持技术人员的真正痛苦
mckaygerhard
于 2016-06-26
正如我所说的@greezybacon由于所涉及的人确实从 fitrs step 接收/发送了正常的电子邮件，然后那些回复了正常的电子邮件，并且所有的威胁都发生在 thiket 威胁之外！ 支持技术人员的真正痛苦
mckaygerhard
于 2016-06-26
还没解决？？
inphower
于 2017-04-28
当然没有解决方案.. 直到像 owncloud 升级到这个项目时发生了类似的事情... 升级一个分支，开发会变慢...迁移到新的分支
mckaygerhard
于 2017-04-28
@inphower见：
greezybacon 于 2016 年 6 月 25 日发表评论
“mckaygerhard 我们不发送最初的电子邮件，因为协作者已经包含在用于创建票证的电子邮件中。为什么他们会收到第二封包含相同信息的电子邮件？”
有：
A：无法与协作者在 UI 中打开工单。
B：与合作者一起开票的唯一方法是通过电子邮件发送票务系统并抄送人员。 DEV 决定不向所有收件人发送两封电子邮件，而不是一封。
ntozier
于 2017-04-28
我再说一遍：所涉及的人确实从 fitrs step 接收/发送了正常的电子邮件，然后那些人回复了正常的电子邮件，并且所有的威胁都发生在 thiket 威胁之外！ 支持技术人员的真正痛苦
mckaygerhard
于 2017-04-28
所以你的论点是：
如果我发送电子邮件至： [email protected]。
并将其抄送给[email protected] 、 [email protected]和[email protected]。
Jon、Mary 和 Jane 不会收到原始电子邮件吗？
ntozier
于 2017-04-28
但是当我们从 osTicket 发送第一个回复时，这只会发送到一封电子邮件，因为第一次输入的 CC 不包括在内，，，
inphower
于 2017-04-28
你知道@ntozier你只会在不止一个用户发出噪音时才注意..我梵蒂冈，如果你们所有人都不注意重要的想法，这将像 ownclud 案例一样结束！
@inphower你说它没有发生，所有在邮件中，抄送和作者，将作为合作者包含在票中......
问题在这里你们大家，就是那些用CC邮寄的人，会在票的威胁之外收到一封邮件......
因此，如果其中之一响应，则该 tiket 显然未收到威胁历史记录，因为它不在响应邮件中。
我的意思是：Jon、Mary 和 Jane 收到原始邮件，但由于“我发送”不仅是票，这些人没有“通知”最终和真正的收件人是“票”
如果在那封邮件之后，Jon、Mary 和 Jane，还有其他人拿着票，那么他们会想“啊，好吧，那是一张票，不是私人谈话”
当然，我们正在与“假”人打交道，这就是票务调查、票务支持或其他任何名称的原因！
所以威胁会很痛苦，因为历史会在发生时失去
mckaygerhard
于 2017-04-29
@inphower我认为你指的是当支持者以作者身份打开票时，当然在这种情况下和 osticket 1.9 系列中这是不可能的，但并不难做到......来自 osticket 人的回应是“使用1.10" 那是 1,5 年前的 .. 在这一刻 1.10 是不稳定的，所以建议在生产中使用不稳定.. 太棒了！
mckaygerhard
于 2017-04-29
现在看来 pull 解决了#3353 看起来很容易，为什么在 1.9 中实现的开发人员在那个时候如此复杂！
mckaygerhard
于 2017-11-22
这个问题在 1.10 仍然发生...... collaboratos 没有显示，也没有通知！
mckaygerhard
于 2020-01-06
@麦凯格哈德
这里的思路是，由于协作者收到了来自用户的原始电子邮件，因此他们不需要收到新工单提醒。 如果这不是您想要的东西，我们非常欢迎您根据自己的喜好修改代码库。
干杯。
JediKev
于 2020-01-07
解决方案似乎在 #3353 中，但开发人员再次不考虑该问题.. 噗，这就是为什么有这么多分叉和“删除”评论的原因
mckaygerhard
于 2020-01-07
@麦凯格哈德
没有“修复”，因为没有实际问题，这就是它的工作方式。 正如我之前提到的，非常欢迎您修改代码库/应用您提到的拉取请求并完成它。
干杯。
JediKev
于 2020-01-07
所以然后拉#3353 所以合并它！
mckaygerhard
于 2020-01-07
嘿拉在#3353 大约 10 年......现在@protich sais：“我们想与社区合作”！？？？？ 嗯...
vegnuli
于 2020-01-07
大家好。 我很高兴与您进行对话，但是我要指出，这与本问题报告完全无关。 请保留有关主题的问题报告。 谢谢你。
ntozier
于 2020-01-07
有什么问题……他在合作，他们还在抱怨
diazvictor
于 2020-01-08
相关问题
lifeofguenter
·
4评论
F3000
·
5评论
roman-1983
·
5评论
joseaguardia
·
4评论
simonnzg
·
5评论
最有用的评论
所以然后拉#3353 所以合并它！