Tickets

This module adds a ticketsystem to Qore.

Installation

To install this module:

This module depends on qore/microsoft-graph. Make sure you install, publish and migrate this module as well.

composer require qore/tickets

php artisan vendor:publish --tag=qore.tickets.config
php artisan vendor:publish --tag=qore.tickets.database
php artisan vendor:publish --tag=qore.tickets.frontend

Upgrade Guide

To upgrade this module:

composer update qore/tickets

If you need to upgrade migrations or Vue components:

php artisan vendor:publish --tag=qore.tickets.database
php artisan vendor:publish --tag=qore.tickets.frontend --force

Usage

Before you can use the tickets module, make sure to do the following things:

1. Add the tickets resource to the GlobalsController.
2. Apply the correct settings to the qore/microsoft-graph plugin if you want to scan mailboxes using the Exchange protocol.
3. Make sure to look at the module settings and edit whatever is necessary

Configuration

You can register your own resources in the tickets.php config for employee, contact and organization. There are already examples present in the config file for the resources provided by the CRM and Employee modules.

All of them work completely, except for the OrganizationResource. The OrganizationResource doesn't store the domain of an organization, so if you want organizations to be automatically assigned to tickets, you must extend the functionality of the OrganizationResource or use another resource.

The tickets module also implements triggers and actions. You can define your own actions by adding them to the config. These actions must implement the ActionType interface.

There are also a bunch of strings and regexes defined in the config that are used for filtering sections from an email message. These can also easily be modified or expanded if the current configuration is insufficient.

Commands

There are two commands that are made available by this module:

1. qore:tickets:prune
2. qore:mailbox:scan

The prune command is used to detect inactive tickets and run triggers depending on the settings.

The scan command is used to scan defined mailboxes.

Both commands contain a tenant argument. If a tenant is specified, the command will only be executed for that particular tenant. If no tenant is provided, the command will run for all tenants.

The scan command also contains a mailbox argument. If a mailbox is specified, only that mailbox will be scanned. If no mailbox is provided, the command will be ran for all mailboxes.

The scan also allows a force tag. If force is set to true, the command will ignore the scan cooldown defined in the settings.

Be sure to run these two commands every minute using a cron job

Also, the command qore:mail should be configured to run every minute using a cron job. This allows emails to be planned for the future.

Settings

The tickets module also comes with a bunch of different settings that can be found and changed at the tickets' settingspage. In this section the different settings will be explained.

1. load_full_timeline & timeline_items_per_page

These settings define the per_page option when querying the ticket posts for the ticket timeline. If load_full_timeline is false, per_page will be 100. Otherwise, per_page will be set to timeline_items_per_page.

2. allowed_mime_types

This setting is a whitelist for MIME types to be added to or downloaded from ticket posts. If a ticket post has a file that is not on the whitelist, it will show a warning when trying to download the file from the timeline. When creating a new ticket post, uploaded files that are not part of the whitelist will be refused.

3. max_file_size

This setting defines the maximum file size for files for ticket posts. When an email gets received with a file larger than the file size, the file wil be ignored. Similarly, when uploading a file greater than the file size when creating a new ticket post, the file will be refused.

4. outgoing_mails_per_department

This setting determines which email address is used when an email gets sent from the ticketsystem. There are a few options available which can be changed by default or per department. For example, a ticket with the department backend will use the outgoing_mails_per_department setting for backend. The available options are receiving_email and logged_in_user. receiving_email means that the email will be used that the tickets has received its initial email from. logged_in_user means that the email will be used of the logged-in user.

5. mail_scan_frequency

This setting determines how often defined mailboxes are scanned. You should have a cron jbo defined that runs the qore:mailbox:scan every minute. Setting the mail_scan_frequency to 5 will the command scan the mailboxes every 5 minutes.

6. mail_send_threshold

To prevent infinite mail loops from happening, this setting will limit the amount of email sent to a particular email address. Setting the value to 5 will set a limit for sending emails to an email address to max 5 times per 5 minutes.

7. mail_forwarding_domains

This setting holds a list of domains which should be checked for mail forwarding. When the ticketsystem receives an email from a domain which is in the list, it will check if the email was forwarded and if so, retrieve the forwarded email and sender and use that for creating the ticket post.

8. Mailboxes

The mailbox resource (not a setting) can also be found on the tickets' settings page. Here you may define mailboxes to be scanned by the ticketsystem.

9. response_to_closed_ticket_action

This setting gives two options for what to do when someone responds to a closed ticket. When create_new_ticket is selected, a new ticket will be created. When reopen old ticket is selected, the post will be added to the closed ticket and the status will be set to open.

10. response_to_closed_ticket_action, close_ticket_after_days, send_ticket_close_reminder and reminder_before_ticket_close_days

These settings determine what should happen when tickets become inactive. Setting response_to_closed_ticket_action to true will activate triggers being sent for inactive tickets. This also activates triggers automatically being closed when they become inactive.

With close_ticket_after_days you can define after how many days of inactivity a ticket should be considered inactive. After this period the ticket will be closed and a trigger will be fired.

send_ticket_close_reminder enables reminder triggers to be sent. You can bind actions to this trigger, like sending an email.

With reminder_before_ticket_close_days you can define when the reminder should be sent. Providing a value of 2 will send the reminder 2 days before the ticket is considered inactive.

11. Actions and triggers

You can define your own actions that can be assigned to certain triggers. A trigger might be fired for example when a ticket updates or an inactivity reminder should be sent. These triggers can be created in the actions and triggers table on the settings page.

Actions can be defined to either send an email or change a ticket field. If this is not enough, you can define your own actions using the ActionType interface and adding them to the tickets.php config file.

There are currently 4 trigger types:

1. TICKET_FIELD_CHANGE which fires when a ticket updates. You can specify a field, so the trigger only gets fired when that field changes. In some cases you can also define an old and/or new value, making the trigger only fire when the old and/or new values match.
2. NEW_TICKET_CREATED which fires when a ticket gets created. You must specify if the trigger should be fired for internal or external tickets, or both.
3. CLOSE_TICKET which fires when a ticket gets closed due to inactivity. You can optionally specify a status, so the trigger only gets fired when the closed ticket had the specified status before closing.
4. CLOSE_TICKET_REMINDER which fires when an inactivity reminder should be sent. Here too, you can specify a status to only fire the trigger for tickets with the specified status.