我是新来的整个OTRS /帮助票系统的概念。
不胜感激，如果有人能提供一个简单的例子来区分组中的用户和与OTRS中的angular色相关联的用户。 什么使得其中一个或多或less有利于另一个。
很长的回答：
概要：
授权 – {（用户，资源，行动）}准许 – （资源，行动）对
组是一组人（用户）angular色是权限的集合
说明：组和angular色是一个混淆和混淆的概念。 我发现如果有什么共识的话，就是用来连接用户和权限（对某些资源采取行动的能力）。 最终，所有授权都与连接用户，资源和行为有关; 例如Jane，并在美国航空123号航class上预订…用户是Jane，资源是AA 123，并且动作是预订。 把这个想象成一个大的3D表格或matrix，一边是我们有用户，另一边是资源，第三边是我们的行动。 这真的很快变大。 我们分得越细，pipe理问题越大。
为了使这个matrix更小，我们把类似的用户放在一起，并把它们称为组。 我们将资源和操作结合在一起，调用权限，并将这些权限组合起来，并称为angular色。 这个想法是使matrix的边（尺寸）更小。 现在我们可以将旧matrix转换为连接angular色和组之一来pipe理授权。
我发现这种思考他问题的方式使其易于pipe理。 不幸的是，现实世界是复杂的，有时候人们想要pipe理系统，在这个系统中，用户将angular色和能力（资源和行动）添加到组中，这种方便使angular色和组合变得混乱。
在这一点上，OTRS似乎有一些语义上的混淆 – 默认情况下，“组”和“angular色”重叠…按照OTRS用户，组和angular色文档 ：
angular色是一个非常强大和有用的function，可以非常简单快速地pipe理和更改许多用户的访问权限。 在拥有许多用户，组和队列的大而复杂的系统中，此function非常有用，有助于节省时间。
…
您不应该同时使用“用户到组”和“用户到angular色”映射，但这会使维护变得非常困难。 因此，如果您决定使用angular色，我们build议您在pipe理区域中禁用用户< – >组选项。
更新：
对于每个公司来说，他们通常是2个代理人 – 一个是主要人员（主要是对问题的回应），另一个是次要人员（如果是一个大工作，则可以作为一个人来应对溢出）。 我的问题是找出以最简单和最实用的方式将OTRS应用于这种情况的最佳方式
考虑到angular色和组映射并不是要一起使用（如果是的话，你可以做Group_<Company> + Role_<Primary|Secondary> ），你可能最终不得不分配Role_<CompanyName>_<Primary|Secondary>
我在这里看不到问题
“组”是权限组，您可以直接将用户添加到权限组，也可以通过angular色执行。 最后一个是最简单的，特别是在有less数用户的系统上。
如果您使用angular色，则可以将大量用户快速分配给一个angular色，然后如果您需要添加一个组，则只需将该组添加到angular色中，而不是手动将其添加到所有可能的用户可能不需要访问。
另外，如果你有一个（半）复杂的权限结构，使用angular色而不是群组通常更容易一次性获得权限的分配 – 想到“哦，这个人应该得到Role_Helpdesk和Role_Incident_Manager，而不是必须记住“那是在服务台上的RW，在networking上注意加上move_into权限，在系统pipe理上注意再加上move_into，再在通知上再次RW”…
你明白了吗？
迈克
简单地说，您使用组的访问权限和pipe理职位的angular色，如：pipe理员，经理，电话中心等，那么你可以将他们的访问权限组分配给常见问题，电话或电子邮件门票等。