In simple terms the difference between a Group and a Role in OTRS Ticket system?

Hey guys

I'm new to this whole OTRS/Help ticket system notion.

Be grateful if anybody could provide a simple example that differentiates between a User in a Group and a User assosciated with a Role in OTRS. And what makes using one of these more or less beneficial over the other.

Thanks in advance.

From serverfault Dan

• It seems like there is some semantic confusion within OTRS on this point - the "groups" and "roles" created by default overlap... per the OTRS Users, Groups and Roles documentation:

  Roles are a very powerful and helpful feature to manage and change the access rights of many users very simply and quickly. On big and complex systems with many users, groups and queues this feature is very useful and helps to save time.

  ...

  You should not use both User to Group and User to Role mappings at the same time though, this would make maintenance really hard. Therefore, if you decide to go with roles, we'd recommend you to to disable the Users <-> Groups option in the Admin area...

  Update:

  for each company their is usually 2 agents - a primary(the main person to respond to problems) and a secondary(acts as someone to catch the overflow if its a big job etc). my problem is figuring out the best way to apply OTRS to this situation in the simplest and most practical way

  Given that role and group mappings aren't intended to be used together (if they were, you could do something like Group_<Company> + Role_<Primary|Secondary>) you'll probably end up having to assign Role_<CompanyName>_<Primary|Secondary>

  Dan : this is what kicked off this question! documentation seems pretty poor in some areas but good in others.
  From danlefree

• Hi guys, I don't really see the problem here...

  "Groups" are permission groups, and you can add users to permission groups directly, or do it via Roles instead. The last one is the easiest, especially on systems with more than a handful of users.

  If you use Roles, you can quickly assign lots of users to one role, and then if you need to add a group or so, just add this group to the role one time, instead of manually adding it to all the users that might or might not need to have access.

  Also, if you have a (semi-) complicated permissioning structure, using Roles as opposed to Groups usually is MUCH easier to get the assignment of permissions right in one time - it's much easier to think "Oh yeah, this guy should get Role_Helpdesk and Role_Incident_Manager instead of having to remember "That's RW on Helpdesk, Note plus move_into rights on Networking, Note plus move_into on Systems Management, and RW again on Notifications"...

  Do you get the idea?

  -- Mike

  Dan : my situation is this..we have a number of clients. the company is small. each person is linked to a company. so a user agent can have a number of relationships - each to a company. for each company their is usually 2 agents - a primary(the main person to respond to problems) and a secondary(acts as someone to catch the overflow if its a big job etc). my problem is figuring out the best way to apply OTRS to this situation in the simplest and most practical way.

  Mike : That's a different question!
  From Mike

• Roles are mainly to define access rights at functionality level - example whether to allow ticket creation, deletion, edit etc.

  Thats what we have in Vision Helpdesk, I think should be same in OTRS too.

  From Zcrafts