我希望能够在查看已分配消息和主题列表时筛选结果，例如按一个或多个标签进行筛选。我不禁觉得这曾经是可以实现的，但现在我遇到了困难。
在我的 Discourse 站点上，查看我自己的已分配列表或同事的已分配列表时，点击 
会显示搜索界面，其中包含“按 @tobiaseigen 搜索帖子”的复选框。如果显示为“搜索分配给 @tobiaseigen 的内容”会更合理。
高级搜索界面中没有按“分配给”进行筛选的选项，但我认为对于使用已分配插件的站点来说，这将非常有益——这是否已在开发路线图之中？
在搜索过程中，我偶然发现了一个关于为搜索的“魔法过滤器”创建帮助界面的旧话题——不知道那个想法后来怎么样了，但我认为这非常棒！或者，至少如果存在一个完整的功能列表，我很希望能看到它。
很遗憾，我们这里只有主题列表的自定义筛选功能，搜索方面还没有。不过添加起来并不太难。这是个很好的功能建议。
考虑到这一点，我们需要什么样的过滤语法？
我在想
status:assignedstatus:unassignedassigned:{{username}}这样合理吗 @tobiaseigen @sam？
我看没问题！谢谢。
那将是对高级搜索的一项了不起的改进！我们目前正使用 Discourse 作为任务管理和工单支持应用程序，实现这一筛选功能将显著提升我们识别待办事项的能力。我们使用 Discourse 仅一个月，就已经深深爱上它了！非常感谢你们提供如此出色的产品！
太棒了！您是否查看过
以及
非常希望能听到您基于实际使用场景的反馈。
好消息！@Ahmed_Gagan 正在着手进行这项工作，我们很快就能投入使用！
@Ahmed_Gagan @david 感谢两位！这将成为我们团队和客户的一大进步。请继续保持出色的工作。
非常感谢 @tobiaseigen 关于 Discourse for Teams 的指引。另外，@david 的消息太棒了！现在管理工作将变得更加轻松。我想借此帖子告诉大家，促使我们转向 Discourse 的“杀手级”功能有哪些。
我们是一个由软件开发人员、功能分析师和系统管理员组成的团队，致力于为中国市场开发商业管理解决方案，当然，我们的路线图也面向全球。我们为客户定制软件，也有自己的原创产品，但目前我们的主营业务是在 Odoo ERP 之上交付服务和扩展功能。在 Odoo 包含的所有应用中，我们专注于会计、库存和人力资源管理模块。正如您可能预料到的那样，我们广泛使用 Odoo，自 2015 年成立以来，其项目管理应用一直是我们最得力的助手。通过其看板界面（类似 Trello），我们的团队能够管理每个实施项目中商定任务的 workflows。然而，项目实施只是与客户公司关系的开始，如果缺乏高效的管理和面向客户的沟通，维护阶段的事情可能会变得棘手。Odoo 确实有一个工单系统应用，可以通过电子邮件与软件用户进行基于工单的沟通，当然，我们一直用它来提供支持服务。通过该工具，快速回答功能性问题很容易，但当收到复杂的错误报告时，必须生成一份单独的文档来辅助开发过程。在这些情况下，我们一直使用 Gitlab 和 Github Issues，甚至使用自定义的版本控制 restructuredtext 文件（通过内部开发的 Python 工具解析），以建立一种与供应商无关的问题报告格式。最终，我们发现自己处于一种境地：待办工作必须至少在三个不同的地方搜索，使用不同的界面和工作流程。无论是外部还是内部沟通，为了完成日常活动都受到了威胁，这促使我们寻找替代的流程和工具，即使这意味着打破我们的“Odoo 中心主义”。Discourse 作为论坛软件早已闻名遐迩，但直到最近进行了一些研究后，我们才了解到其活动管理功能。促使我们尝试它的有三个因素：异步沟通、工作定义的标准化以及在制品（WIP）控制。
Discourse 的帖子就像电子邮件，但更好。在 WhatsApp、Slack、Messenger、Mattermost、Odoo Chat 等众多即时通讯工具充斥的世界里，我们已经习惯了始终处于“警报”模式。由于一切似乎都很紧急，你被迫用简短、快速且肤浅的回复来应对。没有时间思考，没有时间修改。只管写，然后发送。写这篇帖子花了我比预期多得多的时间，但我是完成其他更紧迫的任务后才写的，所以我可以集中精力给出最真诚、最详尽的反馈（对于 Discourse 这样优秀的工具，这是我至少能做的）。写帖子就像发送邮件，但阅读帖子完全是另一回事，而且要好得多。帖子是集中存储的，并在团队所有成员（或授权人员）之间共享。它们可以根据内容或位置（即主题和分类）进行搜索，甚至对未参与原始对话的外部用户或员工开放，这对于存储决策过程及其背景的历史记录非常有用。快速提示：看到 python.org 选择 Discourse 作为其社区管理应用，而不是邮件列表或其他基于 Python 的解决方案，这表明我们在适用性、性能和可访问性方面拥有真正卓越的产品。
这是我们转向 Discourse 的主要原因。根据前面的背景介绍，您可能会想象出一个色彩斑斓且错综复杂的工作环境。我确实有点过于戏剧化了，因为自成立之初，我们就拥有文档化的流程和数字工具来管理我们的活动。但随着时间推移，我们未能实现公司内部工作的“单一表现形式”。是的，我们有咨询活动的任务和支持工单。开发工作由纯文本记录的需求或众所周知的 Git 相关工单驱动。这不是缺乏的问题，相反，是过剩的问题。信息来源太多了，即使在同一个应用（如 Odoo）内部，也存在多种格式（如任务、工单、问题）。当然，我们可以选择上述任何一种工具作为唯一的真相来源，但它们都没有提供一个关键要素：集成的外部反馈。在使用 Discourse 仅仅一个月后，我们终于感觉到我们正在与产品的用户建立联系。他们和我们之间不再有区别，因为我们都使用相同的界面。然而，我们不必放弃对工作管理的控制权，因为某些区域和功能可以受到限制。但最重要的是，通过 Discourse 的主题（Topics），那些类似于博客评论或工单系统的相同工件，我们用来理解客户需求，也可以在我们的私有内部使用分类中，用来表示计划执行的任务、需要处理的问题或需要执行的操作活动。对我们来说，一个主题有多个同义词，根据上下文不同，它们都是有效的：问题、任务、工单、活动、检查清单，等等。一种同质化的工作形态，开放、易于接近且集中管理。我读到，Discourse for Teams 计划推出一个独立于 Discourse 论坛的单独产品，换句话说，Discourse（论坛）和 Discourse for Teams 将被设计为部署为两个不同的实例。我会建议您仔细考虑这一点，因为这种设计将不可避免地割裂组织内外各方目前提供的集成。
最后，通过使用 Discourse 我们得到的最大惊喜之一是，我们终于可以在组织内建立对在制品（WIP）的控制。由于待办工作都具有相同的“形态”，因此很容易制定政策来限制组织在任何时刻应拥有的工作量。通过 Assign 插件，任务被分配给唯一的负责人，该负责人可根据需要寻求帮助（即使用 ‘@’ 提及他人），然后，使用统一的界面（位于 ‘/g/staff/assigned/everyone’），可以控制整个系统中正在进行的活动数量（即 WIP）。例如，目前我们正在进行每人 5 个任务/主题/问题的 WIP 迭代。由于我们有 14 人，这意味着我们团队的最大容量应为 70。这对我们非常重要，因为它有助于为生活中最困难的 endeavor 之一：估算，提供稳定性。根据利特尔定律（https://en.wikipedia.org/wiki/Little’s_law），队列中长期平均元素数量等于其平均到达率或吞吐量乘以每个元素在系统中停留的平均等待时间。因此，在 70 个元素的受限 WIP 下，如果我们每周收到 140 个工单，它们平均将在 0.5 周内完成；如果我们每周收到 210 个，平均完成时间将为 0.33 周。当然，这假设系统处于稳定状态，且积压工作不会无限增长，因此必须通过迭代方式对 WIP 进行适当校准。我们仍然（并将永远）存在一些无法在 Discourse 中表示的工作类型，例如管理电子邮件消息或我们的 CRM 管道，但由于我们大部分待办工作现在都具有单一形态（即 Discourse 主题），实施看板（Kanban）和敏捷实践（如限制 WIP）将变得容易得多。因此，如果 Discourse for Teams 被设计为 Discourse 论坛的独立实例，我强烈建议至少提供一种联邦方式，以保持两个系统中 WIP 的集中和综合视图，否则将是一种遗憾。
希望这篇帖子有助于改进 Discourse 作为沟通和社区建设平台的功能。再次非常感谢，祝大家一切顺利！
