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 associated with a Role in OTRS. And what makes using one of these more or less beneficial over the other.
Long answer:
Summary:
Authorization - set of { (user, resource, action) } Premission - (resource,action) pair
Groups are sets of people (user) Roles are set of permission
Explanation: Groups and roles are a confused and mixed up concept. I have found that if there is any consensus it is that both are used to connect users and permissions (the ability to act on some resource). Ultimately all authorization is related to connecting a user, a resource, and and action; for example Jane and make a reservation on American Airlines flight 123... The user is Jane, the resource is AA 123, and the action is make reservation. Think of this as a big 3D table or matrix along one side we have users, along the other we have resources and along the third side we have actions. This becomes large really quickly. The more finely we divide the resources bigger the administration problem.
To make this matrix smaller we put similar user together into named buckets and call them groups. We combine resource and action and call permissions, and we combine sets of these permissions and call them roles. The idea being to make the sides (dimensions) of the matrix smaller. Now we can transform the old matrix to one of connecting roles and groups to manage authorization.
I have found that this way of thinking about he problem makes it manageable. Unfortunately the real world is complex and sometimes people want administer the system where they add users to roles and capability (resource and action) to groups and this expedience is what makes roles and groups so confusing.
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>
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
In simple terms you use groups for access permissions and roles for management positions like : admin, manager, call center etc. then you can assign them groups of access rights to faq, phone or email tickets etc.
