是的，我100%和你在一起
这也是我的梦想。合并功能很棒！
因为客户通常会开始新的电子邮件而不是用票号回答......而不是将这个答案“合并”到现有票中。

mrsaw12 于 2014-09-10

是的。
甚至问题是没有可以添加的“公共票务链接”。
因此，如果您可以关闭票并说“查看票号：#12345”，即使这也会有所帮助，
这会将员工和用户链接到工单。
一方面，如果无法合并，这可能会有所帮助，另一方面，如果您有票，
接下来，您可以创建一种“逻辑方式”。

但是让我们看看开发人员对此有何看法；）

干杯！

Hannibal226 于 2014-09-11

我喜欢自动链接的想法（参见#12345683）

greezybacon 于 2014-09-11

@greezybacon

我应该为此打开另一个线程吗？

所以这背后的想法是“只是”你点击一个按钮，你可以输入一个票号（或选择，但这很重）。
在此之后，一个链接将被添加到票证中。

同样，问题不在于添加链接本身，而在于只有员工或用户才能查看此链接。
就像我说的那样，您所做的以下问题和更改，从头到尾都可以很好地处理，无需搜索。

但是，您也不能例如在知识库中创建指向票证的链接，这也许也可以更好地解释一些事情。

Hannibal226 于 2014-09-13

我想添加对此功能请求的支持。我的用户非常擅长发送多封关于同一问题的电子邮件而不包括票号，我很快就会忘记解决问题所需的所有必要信息。

合并票会很棒！即使只是通过输入票#。

dak-csis 于 2014-09-16

欺骗https://github.com/osTicket/osTicket-1.8/issues/1068？

提交新问题前请先搜索！

kordianbruck 于 2014-09-16

好吧，一般来说它的引用是一样的。
但另一方面，它与我的解释分开，因为自动链接是合并票证的另一个功能。

所以现在不知道如何处理。

在我看来，第一个“更简单”的步骤是添加一个选项以链接到工作人员和/或用户可以查看的工单。
因此，您可以在尝试寻找解决方案或理解某些东西时创建一种过程/历史。

但是，如果将来有一种“主票”，可以添加新/相同/双票，那将是一件很酷的事情。
这样您就可以获得一张票，并在合并的票证列表中查看所有不同的解决方案、用户方式。

这是我的想法，但我不知道是否有人能理解并认为这和我看到的一样有意义。

干杯

Hannibal226 于 2014-09-16

引用/链接是@greezybacon的原始建议，他们实际上正在研究它，它被称为“问题”。将相似的票组合在一起很有意义，但它与合并不同。通过合并，您只需将所有工单条目“移动”到新工单，链接/分组将需要一个新表。
所以，是的，它与你所说的@Hannibal226 大致相同

kordianbruck 于 2014-09-16

我将在接下来的几天/几周内对此进行编程。并将其作为拉取请求发布。

如果消息按时间排序，我认为“合并票证”并不难。在大多数情况下，如果您合并一张票，您只有“一条”消息。因为它可能是最终用户回答错误/写新电子邮件而不使用回答按钮的新票。

我的想法是：

您有一个“合并到其他工单”按钮。
如果你按下它，它会打开一个弹出窗口，然后你写/搜索你想要合并这张票的票。
比您被要求将发件人添加为合作者（如果不是来自所有者的相同电子邮件）
比您最后被要求关闭“新票”或删除它。
如果您关闭它，则会添加一个包含所有信息的注释，例如：
谁发送它（电子邮件/姓名）时间/日期和关闭票的票号
或者
谁发送它（电子邮件/姓名）时间/日期

最后。
我认为这是一个非常需要的功能。我经常有客户写一封新电子邮件而不使用应答按钮。比我手动关闭新票并将票号添加到“主票”。但是，如果您需要从一张票切换到另一张票以了解发生了什么，这并不是很酷。

mrsaw12 于 2014-09-16

@mrsaw12我可以建议您尝试将其作为插件实现吗？

kordianbruck 于 2014-09-16

@Mrsaw12

这听起来 gr8，我真的很想测试一下；）
就像你说的那样，它根本没有那么复杂，但无论如何我对 PHP 和 MySQL 并不太感兴趣，所以对自己来说很难。

如此巨大的成功，并让我们知道何时完成；）

干杯哥们！

Hannibal226 于 2014-09-16

@kordianbruck

所以无论如何我不确定。
如果您从一张票中获得说它应该被合并和/或链接到任何东西，或者您选择各种票并将它们分组，这是两种方式。

再一次，这太深了，根本没有任何这个功能，我很高兴我们有像@mrsaw12这样活跃的人，他们花了一点时间在这里快速提供帮助。

可以肯定的是，像@greezybacon这样的主要开发人员或 r 旁边的所有家伙都做得足够了，这不应该意味着任何压力或类似的东西。

无论如何，感谢你把想法放在一起，也许有一个解决方案，双方都对结果感到满意，所以我们可以说“是的，它是一样的”；）

干杯

Hannibal226 于 2014-09-16

在接下来的几个月中，我们将增加一张票拥有多个线程的功能（通过“任务”）。看看这是否有助于票证合并会很有趣

greezybacon 于 2014-09-24

@greezybacon很酷，很高兴听到！

Hannibal226 于 2014-09-24

你好！我想知道此增强功能是否有任何更新？非常需要。谢谢！

lilethlachica 于 2015-01-29

+1

fictionedge 于 2015-02-02

@greezybacon很高兴听到并谢谢！

szemy 于 2015-02-05

也在寻找这方面的更新。合并票证对我们的工作流程至关重要，谢谢。

singularitytrav 于 2015-03-03

嗨，大家好，

我使用了很多票务系统，它们都通过相同的基本方法（Ceberus、Zendesk、RT 等）合并。

我希望看到 osTicket 中的合并与大多数其他票务系统提供的一致。

1) 允许代理从任何视图（搜索结果列表、我的票列表、其他列表）中选择多张票并点击合并按钮。

2) 一旦点击 MERGE 按钮

所有数据都合并到一个工单线程中，按日期排序
OLDEST 票号是合并票号的票号
所有合作者和代理人都在新票上

这是一个合并——你把所有东西都放在一个由原始（最旧）事物表示的事物中。

合并和减少重复是大容量环境中最关键的功能，可减少票务中的盲目和不必要的工作。恕我直言，它们是 osTicket 中的巨大特征孔。

richbodo 于 2015-03-03

👍3

+1 丰富的博多

snizzleorg 于 2015-04-03

+1 !!!

尽管有很多合并功能的请求，但没有进展？？？

Eddie-BS 于 2015-04-16

:( 需要很长时间？合并票非常有用。

PeopleInside 于 2015-05-08

合并并不是特别重要，因为它上面有更重要的特性/功能。
我暂时不会期待合并功能。

ntozier 于 2015-05-08

对此感到难过:)但我可以理解你有很多工作。
这几天我在其他开源票中使用了很多合并功能所以..在OsTicket中真的错过了。

好吧，我希望不要忘记这个 Merge 项目。

对我来说，OsTicket 有你要实现/修复的东西：

合并工单（本期）
工单中的主题编辑（已经完成，即将发布，太好了！） https://github.com/osTicket/osTicket-1.8/issues/1173
更正用户注册页面的错误时间https://github.com/osTicket/osTicket-1.8/issues/1842
修复票证链接中的错误https://github.com/osTicket/osTicket-1.8/issues/2024
也许响应主题https://github.com/osTicket/osTicket-1.8/issues/2030
某些雕像的自动关闭票https://github.com/osTicket/osTicket-1.8/issues/2036
而 OsTicket 将是最好的开源

哇很多人都在关注这个:-) 合并票，太棒了！

PeopleInside 于 2015-05-08

期待与热切期待的融合！

我现在在自己中添加代码，所以在 Merge 是添加的功能之一之前不会更新超过 1.9.4。

elzaer 于 2015-05-13

如果存在用于合并票证的稳定代码，为什么不将其添加到主分支？
好像有需求...
合并对我们来说将是一个巨大的进步！

Eddie-BS 于 2015-05-13

是的，合并票证非常用户满。

Inviato da dispositivo 手机。 | 由移动设备发送
Il 13/Mag/2015 07:03，“Eddie-BS” [email protected] ha scritto：

如果存在用于合并票证的稳定代码，为什么不将其添加到主
分支？
好像有需求...
合并对我们来说将是一个巨大的进步！
—
直接回复此邮件或在 GitHub 上查看
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
.

PeopleInside 于 2015-05-13

工单合并对我们来说是一个巨大的好处，因为我们多次遇到这样的情况，用户在两个电子邮件地址下创建工单，我们希望将它们全部合并到一个帐户，目前必须一次完成一个使用更改所有者（或者您必须从后端编写查询来执行此操作，但这总是很危险的，因为您可能会错过软件通常会处理的某些内容）。

GeekSage 于 2015-05-13

将 userfull 也合并相同的用户票但不同的票，因此如果用户 A 制作两个不同的票，则可以合并为一个。

PeopleInside 于 2015-05-13

为此+1。真希望有一天OSTicket也能有这个功能。

amsut 于 2015-05-15

为这个功能+1，如果可以的话，那就完美了

tha023 于 2015-06-22

+1

AlexYoung28 于 2015-06-22

想象一下，如果 Github 没有合并功能......

dak-csis 于 2015-06-22

+1

noex 于 2015-07-08

合并票证将是一个非常有用的补充。我喜欢 1.10rc1 的发展方式，但是代码发生了太多变化，以至于旧的合并调整并不容易实现。我希望我更精通 PHP。

motoridersd 于 2015-07-24

+1

BassemN 于 2015-07-26

+1 很有必要！

kvaps 于 2015-08-10

在 1.10 上实现的非常详细的国际化功能已经完成，现在剩下的另一个功能是合并票证，这对于大容量支持中心来说非常重要。我希望这会引起 1.10 或 1.11 的关注，以便 osTicket 领先于其他解决方案。

+1

arrayown 于 2015-08-13

是的我同意

PeopleInside 于 2015-08-13

+1

开发此功能并将其与 OSTicket 合并需要什么？

尽管 ntozier 评论说“合并并不是特别重要，因为它上面有更重要的特性/功能。我暂时不会期待合并特性。” 基于 +1 和重复开票的绝对数量，我会说需求非常高。

我已经编写 PHP 16 年了。我可以写一个合并方法。我想与 DB 架构的主要开发人员谈谈，以及他们对实现合并的最佳方式的想法。或者我可以查看架构并提出实施建议。但在我做任何这些之前，我想确保我的工作可以进入 OSTicket Trunk。

有这种可能吗？

ooglek 于 2015-11-23

:+1: 对于@ooglek

BassemN 于 2015-11-23

@ooglek
对我来说听起来很好也很合理。 :)

开发者，你怎么看？
@protich
@greezybacon
@nfebuary

Chefkeks 于 2015-11-23

是的！

snizzleorg 于 2015-11-23

:+1:

PeopleInside 于 2015-11-23

@ooglek
很酷，你展示了这个倡议！

我很确定@greezybacon也很感激，但我肯定不知道他们将某人添加到 github 的规则是什么。
也许你可以在旁边创建合并功能？

但我们必须等待开发人员看看。

再次感谢。

Hannibal226 于 2015-11-24

回复：“但可以肯定的是，我不知道他们将某人添加到 github 的规则是什么。”
任何人都可以加入 github 并提出拉取请求。
开发人员将审查更改并接受或拒绝它们。

ntozier 于 2015-11-24

@ntozier
好的，抱歉，我的意思是“osticket”github 部分，一般不是 github，抱歉：P

但似乎@ooglek是可能的 ;)

Hannibal226 于 2015-11-24

这绝对是我希望看到添加到 osticket 的东西。这个功能肯定会帮助我把它卖给管理层，以便在我们使用的另一个票务系统上采用它。

+1

phantomofrussia 于 2015-12-23

将我自己的 +1 加入其中。

我们正在寻求从另一个票务解决方案迁移，合并是必不可少的。我们得到了很多新票，这些票应该是对现有票的回复，并且由于我们需要准确跟踪票的使用情况，我们最终合并了很多。

tmcnag 于 2015-12-29

这几天我一直在思考这个问题。我将在 UI 上工作，我与@greezybacon进行了交谈，他也提到了投入一些精力。（他的日程安排有点疯狂，所以请记住这一点） @ooglek欢迎任何协助，你和我可以讨论UI，您可以与@greezybacon 讨论后端。我认为我们可以做到这一点。哦，+1

nfebuary 于 2016-01-05

有人可能会在合并过程中整理一个更正式的 RFC，以便我们可以解决合并过程中的问题并制定一些关于如何在 osTicket 中完成此任务的定义？我认为到目前为止提出的一些问题：

线程是如何合并的？是来自不同票证的物品：
- 按时间顺序交织在一起
- 折叠工单中的线程被添加到合并工单线程的末尾
- 通过单独的选项卡在 UI 中显示单独的线程
- 不执行线程合并。相反，工单已关闭，“相关工单”链接添加到合并工单
元数据如何合并？具体来说
- 截止日期
- 受让人（员工和团队），以及路由部门
- 添加到相应工单的自定义数据和表格
合并的流程是什么？
- 从工单列表队列中进行多选操作
- 工单视图中更多下拉菜单的操作

我可能会尝试输入一些内容，但我没有强大的功能用例，所以我认为其他人可能会对事情的工作方式有更大的感受和方向

greezybacon 于 2016-01-06

目前有点忙，但我的直接想法是：

逐个选择按时间顺序合并或追加线程
截止日期、受让人等的每项决定
“更多”下拉菜单中的操作

我们当前的问题（通过使用门户网站而不是仅使用电子邮件可能会有所缓解）是用户将打开票证，但在几个小时内没有收到回复（他们可能在我们的办公时间之外打开了票证或我们可以在度假）然后打开另一个询问我们是否得到了第一个。我们要么关闭一个会影响我们会计的公司，要么合并。

另一种情况是人们打开一张票，然后在另一封电子邮件中发送更多信息，由于主题行不同，该邮件将被注册为新票。这也可以通过使用门户来缓解，但我们希望保留允许基于电子邮件的工单的能力。

tmcnag 于 2016-01-06

@greezybacon
我认为首先看到两个选项会很好：

1)
从工单 A 和工单 B 合并（作为链接注释）到工单 C。
通过此步骤，有关合并的信息应自动发送给用户和
关闭 A 和 B。

现在的意思是，当您在“打开”票 C 下看到时，您可以看到旧的或
只需转到链接的选项即可获得更多选项。

2)
从票 A 和票 B 合并为一张新票 C。
功能与上述相同，但 Ticket C 将使用 implement 新建
现有的。

在我看来，这主要需要保持票务系统清洁的东西。

AFTERWARDS 可以直接在工单中切换工单 A 或工单 B
C会很好，但我认为这需要一些时间（主题等）并且不是
对于主要的合并 atm 非常重要。

干杯！

Hannibal226 于 2016-01-06

我认为合并票证不应导致创建新票证

greezybacon 于 2016-01-06

我不会命名名称，但我们当前解决方案的工作方式是，您选择要合并到的工单的 ID，然后另一个将其所有内容替换为一条消息，大意为“工单 ID XXX 已已合并到 ID YYY"。这保留了在没有创建新票证的情况下执行合并的事实。但是，由于我们是根据票的使用情况计费的，因此实际上应该只有一张票，这仍然会留下两张票。

因此，记录所发生的事情很重要，但以干净直观的方式进行记录也很重要。

tmcnag 于 2016-01-06

OTRS 的一种方法是“链接”票证。例如，一张票将被视为“主”，其他票将被合并到它。

在显示中，所有通信都将被“联合”并按时间顺序显示，无论通信来自哪个链接的票证。

这允许父子关系。您还可以“链接”工单，使它们相互关联，但仍然是两个单独的工单。

被视为儿童的票不会出现在“打开/关闭/已解决”显示或计数中。

我同意@greezybacon的观点，即合并不应创建新票。

在我看来，一旦创建了工单，就不应该在 DB 结构中对其进行修改，而应使用软件“合并”它们。这种方式“取消合并”是可能的，尽管新的通信只会被添加到“主”票中，即使旧票收到了新的通信。虽然这并不是真正必要的，但我认为当它们与父/主链接时“冻结”子票会更干净。

ooglek 于 2016-01-06

不是第一种方式，正确的。

但在清理门票时，您通常需要此选项。
所以你认识到新事物的更新或联系。

现在您可以将其添加到现有票证中，但不知道要添加到哪个票证，或者您先创建一个新票证然后合并它们。

为什么没有直接合并到新的选项？

我再次明白，第一种方式的“合并”意味着将事物放在一起，但在最后一个选项中，你可能会创建一张新票来准确地做到这一点。

PS：肯定只有我的两美分：P

干杯

Hannibal226 于 2016-01-06

@Hannibal226 -- 创建新票 -- 客户如何回复旧票？那是怎么处理的？至少在保持数据结构相同并在两张票之间创建链接的情况下，客户可以回复任何一张票，并且回复处理代码不需要更改——它可以进入任何一张票（是的，这不是我建议冻结儿童票的方法，我放弃了选择）。取票时，您需要做的就是：

这张票有小孩吗？如果是这样，请从该工单中获取所有响应并将它们与该工单合并以进行显示。
这张票有父母吗？如果是这样，重定向并显示父级而不是子级
在“打开/关闭/已解决”工单计数和显示中，忽略并且不计算作为子工单链接到另一个父/主工单的工单。

修改要简单得多，因为您不必更改处理传入回复的逻辑......很多。我只是想到了几件事。

状态变化：关闭 Master 是否会关闭子/子？或者孩子/孩子的身份会被忽略吗？
客户对子票的响应应重新打开主票。
主/子之间的状态是否应该同步？

我认为保持现有系统的结构尽可能相似，只在绝对必要的情况下增加复杂性，而不是复制数据或在 ID 上运行更新，这将是最好的，并且可能会减少使其工作的挑战。

ooglek 于 2016-01-06

我个人喜欢“链接”票的想法，我认为合并更像是“一组票”。因此，当用户 Alice、Bob 和 Charlie 报告相同的问题时，这些工单会相互关联，并且代理可以（考虑电子邮件“回复”与“回复所有”功能）然后更新、回复等到所有端用户（Alice Bob Charlie）通过该链接/合并票证或仅单个用户（Bob）。

我认为，如果使用链接的票证这样做，最困难的部分是使 UI 如此直观，以便您作为代理更新/回复/等到“一组票证”（我怎么称呼这）或单票。

从最终用户的角度来看，我认为获取其他用户报告相同的信息并且所有或只有我（作为单个最终用户）现在从代理获得基于感觉和事实的响应是有意义的来自代理的消息。

我认为合并票证真的很难实现，因为有很多方法可以实现，而且票证合并方法也有很多不同的用例。

干杯，
迈克尔

Chefkeks 于 2016-01-06

我们已经讨论过添加“问题”的概念。问题就像工单和任务之间的关系。但是，票证作为父/子关系被装订到问题上。我经常使用的用例是数据中心中断。 IT 小组可能会收到几条源于数据中心中断“问题”的票证通知。因此，可以创建一个新问题，并且所有票证都可以与该问题相关联。对问题的响应将广播给相应的票所有者。当问题关闭时，所有儿童票也将关闭。

我认为合并是完全不同的事情。我们经常认为合并更像是一种替代操作。合并工单时，除最后一张工单外的所有工单都被有效删除。线程只能从剩余的一张合并票中访问。 v1.10 中的电子邮件回复不再与工单关联；相反，它们与线程相关联。因此，如果票证在合并时被删除并且线程以某种方式与合并票证相关联，则对折叠/删除票证的响应将通过其线程在合并票证中继续。

greezybacon 于 2016-01-06

🎉1 👍1

@ooglek

但是当用户回答票 A 和 B 时，你从合并的票 C 中得到了什么？
我认为对于“父母/孩子”的东西，它比刚刚关闭的链接票更复杂。

因此，在我看来，所有用户和协作者都必须合并......

为了保持新票的示例（这不是我们谈论的主要功能），我们总是必须从一张票开始：

所以你在 Ticket B 中创建一个新的 Ticket C，这意味着所有用户和协作者都将像在 B 中一样使用。
然后你必须合并票 A，如果 C 中不存在协作者，它将只包括协作者。

干杯

Hannibal226 于 2016-01-06

@Chefkeks我不同意从用户的角度对票进行分组。这太接近于混合来自不同客户门票的潜在私人信息，并且很容易发生交叉污染。

我确实认为这是问题会派上用场的地方。作为示例工作流程：

三个不同的组织/用户在更新过程中报告了相同的错误，因此我们创建了一个问题，例如“更新时收到错误”，然后将这些票证链接到该问题。然后创建一个任务来解决错误，并将该任务链接到该问题，并通过关联票证。

tmcnag 于 2016-01-06

-抱歉在新应用中按错了按钮-

Hannibal226 于 2016-01-06

我对此非常感兴趣，但它似乎相当复杂。我的要求——（那些可能只是我的）要简单得多。

客户 a 创建了一张票，客户 b（或具有不同电子邮件地址的客户 a）写了关于这张票但没有在原始线程中回答的问题。现在我将邮件内容复制为内部注释，并将第二个电子邮件地址添加为协作者。

这可行，但问题是附件无法通过复制和粘贴传输。
所以对我来说，一个非常简单的合并或附加消息到现有票就足够了。

snizzleorg 于 2016-01-06

@snizzleorg
这不是你的意思更简单，你所做的只是更手动：P

所以我们说要建立一个完整的票的链接，你在谈论从票中发短信。
至少我们都需要相同的方法，但是有几种方法，现在有最方便/有用的方法的问题。

或者你想告诉我一个按钮不会比手动复制和关闭更好吗？ :P
（甚至附件副本也是可能的）

干杯

Hannibal226 于 2016-01-06

好的，我认为@greezybacon解释的“问题”是我对“一组票”的想法。

关于最终用户的观点和来自不同票证的数据安全/私人信息，您可能让我有些误解。
我的想法更像是向所有票证所有者广播的正常响应，因此他们都可以从代理那里获取信息，并且还可以根据票证所有者所属的组织，了解其他用户报告的内容。因此，为最终用户保留单独的票证，但为代理商提供一些可能性，以便更轻松地处理具有相同问题的票证。

话虽如此，阅读 Jared 写的关于“问题”的内容以及他如何将票证合并为完全不同的东西，我不得不承认我更喜欢“问题”，并且觉得这可能是一种更好的方式合并或说处理/管理票证。

迈克尔

Chefkeks 于 2016-01-06

@chefkeks

但是，您不认为为员工提供一张票/广播而对用户来说是分开的（在编码中）变得混乱和复杂吗？

我认为，将现有票证从用户那里替换为或者更好地说是反对票要容易得多。
所以这应该自动发生，当“旧”票被关闭并且新票中的相同用户/合作者 r 时。

用户现在还可以看到在这种情况下发生了一些事情，这可能只是一部分，因为它是第二张票的东西（理论上现在有点 xD）

干杯

Hannibal226 于 2016-01-06

两者都需要。需要处理来自单个用户的多个请求，这些请求应该被合并或“合并”。单独需要将几个不同的请求合并在一起，这些请求通过一个共同的“问题”相关联。问题分组并不意味着授予用户访问彼此票证的权限。但是，它确实暗示了“公共票证”的概念，其中可能会将问题发布到客户端门户，表明“我们目前知道数据中心问题......”

两者应该成为独立的特征。它们不应该组合在一起。

greezybacon 于 2016-01-06

我完全同意这一点！

两者应该成为独立的特征。它们不应该组合在一起。

所以我认为考虑到 Jared 的最后一篇文章，github 上应该有 2 个 RFC 问题，可以相互独立地讨论，但要相互引用，所以人们要么只讨论合并票证，要么讨论问题/票证组.

干杯
迈克尔

PS：由于 osTicket 团队在编码和 UI 设计方面非常有经验，我不担心它可能会让代理和最终用户感到困惑。

Chefkeks 于 2016-01-06

@greezybacon

但为什么这么“复杂”？

用户只能访问他们允许的票证。
那么为什么不总结你想要的，因为用户不能访问例如另一个人的票，如果他们不是合作者呢？
我认为，如果特权运作良好，则不必将其分开。

你甚至可以将“问题”命名为“项目”或“任务”或“组”，但人 x 只能访问主（合并）票证和里面的票证，只要他是该票的创建者或合作者。

也许我认为在这种情况下有点小，但我不确定如果你开始分开这是否会变得很大，因为可能会有新的案件和案件之间的请求，或者？

PS：我只是在考虑用户和几乎实现的方式，对不起，如果听起来很容易并且不确定xD xD

干杯

Hannibal226 于 2016-01-06

“问题”意味着OST用户理解和管理的全新范式。就像@snizzleorg所说，当客户 A 电子邮件和客户 B 电子邮件（或客户 A 来自不同地址的电子邮件）时，这些是我 90% 的合并案例。

有一段时间，很高兴拥有一张票并能够与 A 就某个问题进行沟通，然后与供应商 B 就同一问题进行沟通，但不包括 A，但在 OTRS 中仍然在同一张票上。但我不需要那个，只是很好。

我个人非常不喜欢创建“问题”的想法，因为我告诉系统这两张票实际上是同一个问题，无论谁在票上。

正如@tmcnag提到的，我认为“交叉污染”是用户应该决定的，而不是工具。在某些情况下，您认为我可能想“交叉污染”，但在我看来，它是一种工具。

为什么 Ticket A 和 Ticket B，客户发送了一次电子邮件，然后 5 分钟后再次发送电子邮件说“哎呀没关系”，但没有回复 Ticket A，为什么这应该成为“问题” - 他们真的是只是一张客户未能通过流程制作的一张票。我只想检查两张（或三张或四张）票并“合并”它们（IMO 链接它们以防我错误合并错误的票）并拥有一个统一的响应和对话时间表，让我可以管理一切即使客户没有通过回复正确的电子邮件来“做正确的事”，也可以按照_I_ 的意图在一张票中。

我认为添加“问题”会使这一切变得更加复杂——90% 的案例将是客户通过电子邮件发送两次关于同一件事的信息，我希望它们在同一张票中。

ooglek 于 2016-01-06

同意@greezybacon——问题是一个有用的概念。合并票证是一个有用的功能。它们应该单独开发而不是增选。

ooglek 于 2016-01-06

我喜欢一种类似于超级票的新型票（问题）的想法。这可以用于将多张票合并成一个问题......甚至在/如果发生影响许多人的大事时由工作人员打开。就我个人而言，我很少在我的任何一个实时站点上使用它。但我可能想将它们用于定期维护、大型网络中断等。

话虽如此，我可能会更频繁地使用合并功能。我希望它会像我们现在手动执行的那样。这是更新一张票（后来创建的一张），说已经为此问题打开了一张票（参考票号）关闭重复票。然后使用任何其他信息更新原始票证，并将第二张票的开启者添加为合作者。

ntozier 于 2016-01-07

我与@ooglek问题和合并将是两个不同的事情。合并对我们公司最有用，而问题概念 - 不确定我们是否需要。虽然很好...

snizzleorg 于 2016-01-07

感觉还是有些迷茫。

合并票证、所有者、线程和数据是：

是什么导致“污染”
帮助在相同的数据和通信线程中防止同一个人或同一组人出现相同的问题
（可能）在合并到另一个时删除票证

通过问题关联工单

将（所有）事物分开
允许就“相关”问题进行单独的沟通、数据、所有者、合作者
将“相关”工单添加到工单视图
向系统添加一个新的项目列表，“问题”
允许大众传播和关闭

greezybacon 于 2016-01-07

@greezybacon总结得很好。所以基本上有两个新功能

snizzleorg 于 2016-01-07

@snizzleorg我建议这就是这两个功能的工作方式。我希望通过建议两个不同功能的不同目的来消除一些混乱。我的希望是让每个人都在同一个页面上，这样我们就可以继续推进 RFC 和功能的实现。

greezybacon 于 2016-01-07

好的。如前所述，我对合并更感兴趣，并认为至少这个功能布局得很好。如果两个初始票证不同并且解决票证数据本身的冲突，问题仍然是如何选择所有者生成的票证。

我建议：

1 + 合并 2 = 票证 1 的数据/所有者

2 + 合并 1 = 票证 2 的数据/所有者

snizzleorg 于 2016-01-07

我投票让用户（代理）选择合并后的票证将拥有哪些数据。

所以给用户一个他可以的合并票证数据的预定义/建议
A）接受并继续合并或
B) 完全改变合并的方向（所以 2 +merge 1 = 票 1 的数据/所有者而不是票 2）或
C) 在工单合并之前编辑单个字段（例如帮助主题）

Chefkeks 于 2016-01-07

@greezybacon关于合并票证，我认为合并对用户的影响以及后端合并的实际方式存在一些混淆。

污染——如果两张票在数据库中分开保存，则没有污染。在“合并”操作时，将创建两个工单之间的“链接”和关系类型（工单 3 是工单 4 的子代，工单 4 是工单 3 的父代）。软件将使链接的工单状态保持同步——当父工单状态更改时，所有子工单状态都会更改。当子工单收到电子邮件通信时，会更新该工单通信，然后在所有链接的工单中同步子级的任何状态更改。工单 4 将显示工单 3 中更新的通信。在这种情况下，不会有污染，并且您始终可以在几乎没有影响的情况下取消链接（取消合并）这两个工单（我能想到的唯一影响是如果您添加了合作者从合并时的子票证到父票证，并且您可能不想在取消合并时撤消该操作）。
留住合作者——我相信 90% 的合并将来自同一个人，要么来自同一封电子邮件，要么来自同一个人管理的两封不同的电子邮件。这 10% 的关注只是大量记录（以及在合并时的 UI 中）将要做什么（自动将协作者从子票证添加到主票证）并确保用户知道如果这不是他们想要的，撤消它。或者添加一个默认选中的复选框“将工单所有者合并到父/主中的协作者”，如果您取消选中，则不会在父级中修改协作者。
删除票证——不！不要这样做。那很糟。

问题是一个新功能，到目前为止（据我所知）尚未设计、未指定和无定形。您可以使用问题来合并工单吗？完全！但这真的是问题功能的意图，即合并工单吗？或者您是否因为看起来更容易而使问题复杂化以启用合并？

如果问题是多个客户遇到的常见问题，OST 的用户/管理员真的希望在列表中看到一堆“合并票证”问题吗？对于许多 OST 用户来说，他们可能不需要问题，如果合并票证“创建”了问题，我会感到困惑。当它成为问题时，您会丢失票证的上下文 - 现在我必须以与普通票证不同的方式处理“合并票证”，并切换到 OST 中完全不同的区域来管理合并票证，然后超出规则，普通票在OST中的升级和操作。

我真的非常强烈地感觉到，对于 OST 开发和 OST 用户来说，使用问题来实现合并票证将带来更多的问题和挑战，而不是在现有票证框架内找到一种非破坏性地实现合并票证的方法，因为他们今天存在，在数据库中添加了一个或两个表以及一些代码和触发器来处理链接的工单上的操作。

@snizzleorg我认为您误解了@greezybacon 的评论——他不是在说“两个不同的功能”，而是说“问题可以干净利落地解决所有问题”。上面我不同意。

ooglek 于 2016-01-08

@ooglek您正在结合问题（链接票证）和合并的概念。你怎么能合并两件事情并最终得到两件相互联系的事情？合并的想法意味着将多个事物合并为一个事物。因此删除合并的项目。

greezybacon 于 2016-01-09

@greezybacon @ooglek

我对此的看法是，在数据库视图 ooglek 是正确的，不应该只是删除票证。
在使用/界面站点上，greezy 是正确的，您必须隐藏/替换旧的东西，否则合并是毫无意义的。

但是，为什么这么复杂？
为什么票证只是通过合并关闭（可能是特定的合并状态）？

这意味着通过主工单/问题仍然可以访问或更好地查看工单，但不能再更改。
或者可能会实现一种快照，所以你可以切换它等等......（但这是后来的设计）

这就是合并和发行可以分开的地方（我的观点），因此在合并关闭的票证时，它是“开放”票证的列表。

干杯

Hannibal226 于 2016-01-09

@greezybacon合并是一个 UI 概念，而不是后端概念。从用户的角度来看，工单看起来是合并的，因为一旦他们采取了合并操作，他们就会看到主工单在他们看来按时间顺序排列了所有对应关系，并且回复到所有已合并（或在合并时排除）的各方）。所以用户会看到一张合并票。

在后端，您希望使事情尽可能干净和可撤销。通过在 2+ 个工单之间创建关系，您可以：

通过电子邮件接受对子票证的回复，因为该票证仍然存在——不需要额外的代码或数据库结构来处理包含不再存在的票证的传入电子邮件。
取消合并——回复将保留他们各自的票——唯一挥之不去的问题是合并的合作者——这也可能在取消合并中处理
History -- 工单历史依然存在，可直接查看，无新软件改动
Open/Resolved/Closed 视图——因为从用户的角度来看，子票是合并的，所以子票不会在这些视图中列出。

为了以这种非破坏性的方式实现 Merge，我看到了三个主要的变化和一个小的特性/功能添加：

关系表。将票证链接到具有关系类型的另一个票证。
修改工单的打开/已解决/已关闭视图。不包括儿童票。
修改查看工单。实时合并来自父母和儿童票的信件——例如，从信件中选择*，其中票在（票A，票B）按receiveDate desc排序。并且在查看 Child 票证时，请明确它被主动标记为 child 并且是只读的，您无法对其进行响应。添加指向主工单的链接。
新代码：合并添加关系，并复制（可选复选框，或者更好的是，包含所有客户和合作者信息的多选框）客户和合作者作为主票的合作者。

这大大简化了合并，允许您不修改大量代码来处理“合并”票证，留下历史痕迹，以便您可以调查票证何时“合并”或“未合并”，并且几乎完全无损（合作者大师票中的修改可能被解释为破坏性的；我不认为是，但我不想打折这种观点）。

@Hannibal226 ，我似乎在大多数观点上都同意。我不认为合并的子票应该关闭——我认为当主状态改变时，子状态改变，反之亦然。

例如，如果主票是“已解决”，而持有子票的客户通过电子邮件回复，则子票应返回“打开”，因此主票和所有其他子票也应返回“打开”。

如果您将所有子票证关闭为“已合并”，那么您必须更大幅度地修改处理新传入电子邮件的逻辑。工单状态为“已合并？” 原来的童票还要加上对应的吗？或者现在您是否修改了 Master（如果合并是昨晚犯的错误，我认为这可能会导致一团糟，客户回复了三个不同的时间，然后我去取消合并他们 - 现在是客户 A 的信件在客户 B 的票中。

ooglek 于 2016-01-11

@ooglek

因此，您想以您的方式打开票证 A、B 和“主”C，直至邮件进入票证 A。

但是在不知道代码的情况下，当邮件进入 A 时，我至少会说这很困难/容易，这是来自 C 的合并邮件。
这意味着只有 C 更改为在线。
所以这里只需要一个例程（标志或通过关系表[如未提及]）。

合并的感觉是清理。因此，在合并时打开也合并的票证是不必要的，因为保持它们打开。（在我看来）
因此票证 A 和 B 在合并后立即变得不可见/被替换（对于所有用户和协作者），因此它们可以被关闭（完成/忘记）。
在大多数情况下，您再也不需要它们了，那么为什么要保持状态变化呢？
只有在少数情况下，您可能想要检查某些内容，因此您可以通过链接访问它，并在最后一个选项中取消合并。

所以我看到我们同意：

不收票
问题不是合并，但合并可以处理问题（至少我这样理解你）
合并/取消合并功能
主要合并 UI，只合并较少的 DB

但我们实际的不同观点可能是：

child - master（因为我认为 DB 比 UI 多）
状态改变了所有票，而不仅仅是“主人”

干杯！

Hannibal226 于 2016-01-11

@汉尼拔226

我的场景是这样的：

客户 A 发送电子邮件，创建工单 A
客户 A 电子邮件，相同的电子邮件地址，创建票证 B
客户 A 电子邮件，不同的电子邮件地址，创建票证 C

OST User/Agent 决定使用 Ticket A 作为“Master”并将 Ticket B 和 Ticket C 合并到 Ticket A。

OST 创建链接关系，Ticket B 是 Ticket A 的子节点
OST 创建链接关系，Ticket C 是 Ticket A 的子节点
由于这三个工单中有两封不同的电子邮件，因此 OST 用户/代理决定将除 Master 之外的其他用户合并为合作者；客户 A 电子邮件 B 成为工单 A 的合作者

现在我们完成了。

如果客户 A 向工单 C 发送电子邮件，则该通信将添加到工单 C，就像现在一样。如果该对应触发了状态更改（已解决 -> 打开），票证 C 的状态会改变，就像现在一样，但也会更改票证 A 和票证 B 的状态以匹配。

如果客户 A 向工单 B 发送电子邮件，也会发生同样的事情。

如果客户 A 向工单 A 发送电子邮件，也会发生同样的事情。

当 OST 用户/代理加载票证 A（合并的主票证）时，他们会看到来自票证 A、B 和 C 的所有对应关系，内联。我们可以或可以选择不显示它们来自工单视图中的合并工单。

当 OST 用户/代理加载票证 B 或 C 时，他们会看到一个通知，指出这是一个链接的子票证，带有指向主票证的 URL 链接，并且此处的所有内容都是只读的，必须在主票证内完成回复票。

我不太确定你在第二段中的意思。你能改写吗？

第 3 段：我仍然不同意应关闭儿童票（在您的说明中，票 A 和票 B）。当客户回复该儿童票时会发生什么？现在您必须修改如何处理处于新状态（Closed Merged）或处于状态加关系状态（Closed + Child）的工单，然后添加逻辑以更改 Master 的状态。如果状态为已关闭，则不应将通信添加到该工单，而应将其添加到 Master。但是，当您这样做时，您将失去取消合并的能力，因为现在发往 Ticket A（子）的通信在 DB 中写入 Ticket C（主），如果您取消合并，您如何将通信拉入票 C（主）意味着票 A（子）回到票 A？

我相信客户会长期持有门票——我曾让客户通过电子邮件回复两年前开过的门票——我想确保这些门票得到解决。

我认为我们的协议如下：

不收票
提供合并和取消合并功能
合并主要是 UI 更改、最小的数据库更改以及最小化代码和流程更改

我们不同意：

如何实现子主关系
**我：只是一个关系表
** 你：？？
问题
** 我：问题是该线程中提到的一个单独功能，但 IMO 与合并功能的实现无关
** 你：？？
主子票的状态
** 我：我认为主工单和子工单状态应该保持同步，以便客户可以回复任何工单，并且该对应关系进入客户预期工单，以便在 Unmerge 期间保持一致性并且不会混合意外回复
** 你：？？

我期待您分享您对我们不同之处的看法。

是否有开发者的 OST 大师组？有什么流程吗？

ooglek 于 2016-01-11

@ooglek

如何实现子主关系**我：只是一个关系表**你：？？
主子票的状态**我：我认为主子票状态应该保持同步，以便客户可以回复任何票，并且该对应关系进入客户预期的票，以便在 Unmerge 期间出现是一致性并且没有混合意外的回复**你：??
- 首先，我们将“主子”关系和关系表紧密结合在一起。
- 所以我在这里同意，但不是通过多张票来管理状态。
  
  在我看来，重新打开订单状态更改应该只对“主”（在我们的示例 A 中）产生影响。
- 只要它被合并，所有通信都应该“重定向”到主控。因为为什么你应该使用合并，当你想在票 B 或 C 之后添加一些东西时？ [因此取消合并]
问题**我：问题是该线程中提到的一个单独功能，但IMO与合并功能的实现无关**你：??
- 因为问题：你是对的，我们可以在其他时候讨论这个：P
  
  我认为只有不同的状态处理（与主控分开）和新的票证创建可以带来问题功能，而无需在这里完全“重新设计/实施”事情。

我很高兴对这个“功能请求”的兴趣和运动；）

干杯！

Hannibal226 于 2016-01-12

@汉尼拔226

关系——同意
票证状态——我建议我们保持状态与 Master 和 Child 同步的原因是因为有一封发往 Child 的电子邮件。
- 如果我们“关闭”儿童票，我们将如何处理这封新电子邮件？如果我们将它添加到 Master 的通信中，那么我们将无法干净地“Unmerge”。如果我们将它添加到 Child 的对应关系中以允许安全地取消合并，现在我们必须撤消会使 Child “打开”的现有状态更改代码，但现在我们必须抑制它并且只将 Master 更改为“打开” ”。这是一些根本性的变化。
- 如果我们让子/主票保持同步，新电子邮件将进入子票，更新子状态，并且（添加代码，不修改现有代码）触发其他子票和主票的状态更新。这是一段添加的代码，而不是新电子邮件处理代码中的逻辑更改。
- 我认为后者更简洁，保持逻辑不变，只需为上述关系表中的票证添加一个额外步骤。
问题——我们同意！ :-)

@greezybacon很想听听你的想法。这是您希望我分叉、修改然后提交拉取请求的事情之一吗？还是你想实施？

ooglek 于 2016-01-12

@ooglek

票证状态
- 触摸。我忘记了取消合并的选项，如果邮件在合并时直接进入，那肯定会更容易和更有条理。

很高兴看到我们在这里聚会：P

干杯；）

Hannibal226 于 2016-01-12

合并 UI 可以与此处的可折叠线程功能一起使用：#2699

我认为我们应该在票证列表上有一个图标，指示票证是否已合并票证。然后代理将知道他们是否可以从工单列表或实际工单视图中取消合并。

需要有一个合并的系统事件以及它在工单视图中发生的时间。正在合并的工单需要有一个单独的颜色指示器，显示它们是线程内的合并工单。喜欢消息和笔记的颜色。

在响应对话框的底部，它可以列出合并的所有工单的电子邮件地址，并且代理可以在响应时手动删除它们。或者使用发送按钮上的下拉菜单选择“全部回复”或“回复父票”。全部回复可以使用手动删除选项自动填充发件人地址。我在这里大声思考。

在检查票证并选择合并后的实际合并中，选择一个模式，其中包含关于什么票证是父票的选项？保留哪些电子邮件地址用于发送回复？执行合并后关闭、声明或转移票证的选项应该可用。可能是附加合并或按日期随机合并合并的选项？以后我会考虑其他的。这纯粹是 UI 的想法，我会让你们讨论后端，我会努力跟上。：微笑：

nfebuary 于 2016-01-12

+1

Hannibal226 于 2016-01-13

+1

kajla 于 2016-02-08

你好，

关于这个想要的功能的任何消息？

jakobkj1 于 2016-07-05

+1

XHAGBARD 于 2016-07-11

👍1

+1

rpfps 于 2016-08-16

我已经为我的版本（v1.9.12）完成了它。功能如下：

用户（访客）Foo 使用电子邮件[email protected]发送到系统，它创建票证 X-1234。
用户 Foo 忘记了他用于票证 X-1234 的电子邮件，然后他使用电子邮件[email protected]发送到系统。现在电子邮件主题是新的并且没有票号。系统创建票证 X-2345。
工作人员（代理）将打开工单 X-1234，选择合并工单。票据 X-1234 及其线程的形式将保留。 X-2345 的线程将合并到 X-1234。 X-2345 的表格详细信息将留待进一步检查。

phamquocbuu 于 2016-08-16

👍1

@cosmospham听起来和我需要的完全一样。你有一个分支或某种方式来下载你的代码吗？

snizzleorg 于 2016-08-16

@snizzleorg抱歉，因为这是一个私人仓库。因此，我只能为您捕获提交更改。查看 03 截图文件的变化https://github.com/cosmospham/test-0

首先，添加一个菜单。
其次，添加路由规则。
然后创建一个 ajax 对话框。
然后编写合并函数。
注意：合并后只刷新页面。

我想你能理解他们。

phamquocbuu 于 2016-08-17

我公司目前在以下场景使用合并票证功能：

我们的票务系统有监控警报。假设我们收到防火墙关闭的警报。然后我们在 30 分钟后收到一张票，说明防火墙已备份。然后我们要做的是合并两张票并关闭它。当合并发生时，它会合并两个票证，首先创建的票证保留为票证，而新进来的票证将成为票证历史记录的一部分。
关于问题的用户电子邮件。然后再次就同一问题发送电子邮件，但由于他们没有通过电子邮件发送主题中的票号，因此系统会为同一用户打开的同一问题制作另一张票。将两张票合并在一起，第一张票保持可见，第二张票打开成为票历史的一部分。

能够将一堆相关票证组合成一个父“问题”是一个非常好的主意，但我认为它应该与合并功能分开（正如其他人所认为的那样）。

phantomofrussia 于 2016-09-23

+1

michaelrimbach 于 2016-10-09

+1，这个功能对我们来说非常有价值。我们的用户中有一个非常重要的部分使用电子邮件客户端来回复 osticket 电子邮件通知，该客户端不符合 osticket 预期的标头

ericLemanissier 于 2016-11-22

自 2009 年人们在 osticket 论坛上讨论以来，这是对合并票证功能的巨大需求。
而且我也会不时检查任何更新，但遗憾的是，只有一次又一次地等待。

为什么这个功能如此重要（在公司内部）？

如果其中一项服务出现故障，并且有 10 位用户针对同一问题向您反馈，则将创建 10 个工单。
如果服务提供商或供应商为您解决了问题，并且您想作为关闭工单文档附加，则无法将消息转发到 osticket 并合并现有工单。您必须复制内容或另存为 pdf 才能上传。但是，您的服务提供商附有许多附件的消息怎么样？您将有许多手动工作要做。
一个用户创建一个新的工单反馈一些系统问题，但实际上我们在一年前就已经提供了解决方案。为什么需要将旧票与新票合并？因为与办公室工作人员打交道，你需要刷新他们的记忆，让他们知道他们重复问同样的问题。