Sprache wechseln auf deutsch
Znuny Professional Services

The ((OTRS)) Community Edition Fork with long-term Support (LTS)

Znuny Unleashed: Supercharged Access Secrets and Permission Wizardry!

Access and permissions are two related but distinct concepts in computer security. Access refers to the ability to read, write, modify, or execute a resource, such as a file, a folder, a program, or a network connection. Permissions refer to the rules or policies that determine who can access what resources and how. Permissions are usually set by the owner or administrator of the resource, and can be based on factors such as user identity, role, group membership, or context. Permissions can also be inherited from parent resources or overridden by child resources.

In Znuny, access and permissions are fundamental aspects that govern how users interact with the system and its tickets.

  • Access primarily concerns the ability of a user to log in to the system and navigate through its interface to view tickets. This encompasses the entry point for users to interact with the platform, allowing them to see the tickets present within the system.

  • Permissions, on the other hand, delve into the specific actions users can perform once they've gained access to the system and its tickets. These permissions are granular and define the scope of actions a user can take on individual tickets. This includes creating new tickets, editing existing ones, closing resolved issues, assigning tickets, or even altering certain ticket attributes or properties.

In Znuny, roles and groups play pivotal roles in managing both access and permissions:

  • Roles: These define the set of permissions granted to a user. For instance, a role might include permissions to create and close tickets but not reassign them. Roles essentially outline what actions a user is allowed to perform within the system.

  • Groups: Groups determine which tickets a user can access. This segmentation allows for ticket segregation based on various criteria such as department, project, priority, or any other defining factor. Users belonging to specific groups will only be able to see and interact with the tickets associated with those groups.

Users within the organization can have multiple roles and belong to various groups simultaneously. This setup allows for a tailored approach, aligning user responsibilities and functions within the organization with the corresponding access levels and permissions they require within the ticketing system.

Administrators hold the responsibility of assigning roles and placing users into appropriate groups based on their job functions and organizational requirements. This helps ensure that users have the necessary access to fulfill their duties without granting unnecessary permissions that might compromise security or the integrity of the ticketing system.

Best Practice

Out-of-the-Box, Znuny is designed to allow the assignment of a user directly to a group. This is also the first screen after creating a user. To enforce best practices in system design, the following settings should be disabled, thus preventing poor settings by assigning a user to a group.

  • Frontend::Module###AdminUserGroup
  • Frontend::NavigationModule###AdminUserGroup

Special Access

Next to the access provided by the standard permissions modules, there are other modules that can be configured and used to provide access to tickets. This access is based on having a link to the ticket, as search requires permissions via roles, and these special modules provide access to the ticket and then apply special permissions for this access.

Special Permissions Module

Activating one of the following modules will grant a user access and permissions to the ticket via a link.

  • Ticket::Permission###5-CreatorCheck
    If you are the creator of the ticket.
  • Ticket::Permission::CreatorCheck::Queues
    Special permissions for this ticket, based on queue.
  • Ticket::Permission###6-InvolvedCheck
    If you were involved in the ticket.
  • Ticket::Permission::InvolvedCheck::Queues
    Special permissions for this ticket, based on queue.

Enabling these modules and using notifications to deliver links to users can extend access to users who usually do not have permissions on a queue via the agent interface. A best practice is used in HR queues or other queues where a user should not have general access but should be allowed to access certain tickets. This is applied system-wide, and a similar feature can be actively used by the agents, when using the mention feature.

Overall, this structure of access and permissions within Znuny offers a robust framework for managing user interactions with tickets, maintaining security, and aligning user capabilities with their organizational roles.