Book a Demo

Ticket access (TicketPermission)

Ticket access (TicketPermission) is a mechanism for granting point rights to one specific ticket .

It is used when a user, group, or service account needs to open a single ticket without access to the entire space .

TicketPermission does not replace space access : it does not grant rights to other tickets, space settings, or participant management.

Core model

For one ticket + subject pair, a single current access record is stored.

If a new grant command arrives for the same ticket and the same subject, the system does not create a second independent access record; it replaces the state of the current row.

This means:

  • MANUAL and TASK are not stacked;
  • previous access is not stored as a separate layer;
  • the last controlled grant command determines the current access state.

Access subject

Ticket access can be granted to one subject:

  • a user;
  • a group;
  • a service account.

Exactly one subject must be filled in a single record.

Access levels

READ

Allows opening and reading the ticket.

COMMENT

Allows reading the ticket and leaving comments.

EDIT

Allows reading, commenting on, and changing the ticket.

This level does not grant the right to manage ticket access or space settings.

Additional capabilities

SIGN

SIGN allows signing documents or attachments if the action requires a separate signing right.

SIGN does not grant the right to change ticket fields.
If the user can change the ticket through EDIT or a broader access, the ability to sign is considered part of the broader access.

Access source

MANUAL

Manual access granted by a user who has the right to manage ticket access.

This access can be edited and deleted through the access management interface.

TASK

Access granted by a task or process scenario.

TASK access is linked to a task, and that task must belong to the same ticket.
This access is displayed as process-driven and is not edited directly through ordinary CRUD operations.

TASK can be replaced by a new controlled grant command. For example, a user with access-management rights can grant manual access to the same subject; after that the row becomes MANUAL and is no longer linked to the task.

Expiration

The expiresAt field sets the access expiration time.

  • If expiresAt is not specified, access is perpetual.
  • If the time has expired, the grant is no longer considered active.
  • Expiration does not restore previous access, because previous states are not stored as a stack/history.

Replace-current semantics

MANUAL and TASK access records are not stacked. The system stores one current access record for the ticket + subject pair.

A new grant command replaces the current state:

  • if TASK replaced MANUAL, the old manual access is not restored after TASK expires or is revoked;
  • if MANUAL replaced TASK, the row becomes manual and loses its link to the task;
  • if TASK from one task is replaced by TASK from another task, the current row is linked to the latest task.

API

The main grant command:

POST /api/ticket-permission/actions/grant

It accepts a scalar request, supports MANUAL and TASK, creates access if the row is missing, or replaces the current state of an existing row.

The ordinary:

POST /api/ticket-permission

is kept for compatibility with manual access grants and supports only MANUAL.

CRUD restrictions

TASK access cannot be edited or deleted directly through ordinary PUT / DELETE CRUD operations.

This protects process-driven access from accidental manual change. If such access needs to be replaced, a controlled grant command is used.

After replacement with MANUAL, the row becomes manual and can be edited or deleted like ordinary manual access.

Uniqueness restrictions

The database stores one access row per ticket and subject:

  • ticket_id + user_id;
  • ticket_id + group_id;
  • ticket_id + service_account_id.

sourceType, task, and expiresAt are not part of uniqueness, because they are the state of the current access, not separate history records.

What is not supported

The system does not support:

  • access through Permission.ticketType as the current model;
  • several simultaneous MANUAL and TASK access records for one ticket and subject;
  • automatic restoration of old MANUAL after TASK expires or is revoked;
  • a history of all grant events inside TicketPermission;
  • direct editing or deletion of TASK through CRUD.

Examples

No access → MANUAL READ

The user was granted manual READ.
They can open and read this ticket, but do not receive access to the entire space.

MANUAL READ → TASK EDIT until Friday

The user had manual READ.
A task granted TASK EDIT until Friday.

The current access became TASK EDIT until Friday. The old MANUAL READ is no longer stored as a separate active layer.

TASK EDIT expired

When TASK EDIT expired, the access stopped being active.
The old MANUAL READ was not restored automatically.

TASK READ → MANUAL COMMENT

A user with access-management rights granted the same subject manual COMMENT.

The current access became MANUAL COMMENT, and the link to the task was cleared.

TASK from task-1 → TASK from task-2

If one task granted TASK access and then another task granted access to the same subject for the same ticket, the current row is replaced with the data from the last command.