Subticket Manager: Configuration
Configuration of the osTicket Subticket Manager plugin: the "Remove Data on Uninstall" option, form fields without effect and the debug mode via the SUBTICKET_DEBUG constant.
Subticket Manager: Configuration
The plugin works without any settings. All features are active after activation. You reach the plugin configuration in the Admin Panel under Manage → Plugins → Subticket Manager.
Option with an effect
| Field | Key | Default | Effect |
|---|---|---|---|
| Remove Data on Uninstall | remove_data_on_uninstall |
off | On uninstall the plugin drops its tables, the version column and the indexes (see below) |
The field carries the description "Delete all subticket metadata when plugin is uninstalled (WARNING: This cannot be undone!)".
If the option is enabled, uninstall() performs these steps:
- Drops the tables
ost_ticket_progressandost_ticket_hierarchy_metadata. - Removes the
versioncolumn fromost_ticket. - Removes the indexes
idx_ticket_pidandidx_ticket_hierarchyfromost_ticket.
The parent/child relationships themselves are kept because they live in the osTicket column ticket_pid. The deployed files in scp/ are always removed on uninstall, regardless of this option.
DROP COLUMN IF EXISTSandDROP INDEX IF EXISTSare MariaDB syntax. MySQL rejects them. On MySQL theversioncolumn and the indexes may therefore remain, and only the tables are dropped.
Fields without effect
The configuration form shows nine more fields: Maximum Hierarchy Depth, Maximum Children per Parent, Auto-close Parent Ticket, Cascade Hold Status, Cascade Assignment Changes, Show Subtickets in Queue, Require Parent Ticket to be Open, Allow Nested Subtickets and Notify on Auto-Close. None of them is evaluated. The plugin does not close parent tickets, does not hold or reassign children, limits neither depth nor number of children and does not hide children in queues. You can ignore these fields.
The values are copied into an internal cache on startup but never read anywhere. The rules the plugin actually enforces are listed under Technical details.
Debug mode
Debug mode is not a form field but the PHP constant SUBTICKET_DEBUG. The plugin defines it as false if it is not yet defined. You enable it by defining the constant before the plugin loads, for example in include/ost-config.php:
define('SUBTICKET_DEBUG', true);
Alternatively you change the line define('SUBTICKET_DEBUG', false); at the top of class.SubticketPlugin.php. That edit is lost on update.
In debug mode the plugin writes timestamps, SQL queries, ticket IDs and subject lines to the file /tmp/subticket-debug.log.
Enable debug mode only for troubleshooting and remove the constant afterwards. The log file contains ticket data and lives in
/tmp.
Browser flag window.SUBTICKET_DEBUG
The comment at the top of js/queue-indicator.js mentions a flag window.SUBTICKET_DEBUG = true that you could set in the browser console. The code does not read this flag. Setting it has no effect, and the panel's JavaScript has no debug switch. The panel (subticket-panel.js) always writes its messages with the prefix [Subticket] to the browser console, and the queue indicator writes errors with the prefix [SubticketManager].
Texts and language
The labels in the ticket panel (for example "Link to Parent", "Create Subticket") are hard-coded in English and are not translated. The overview page subtickets.php is mixed: the heading reads "Ticket Hierarchies", while the intro text and the table headers (Parent-Ticket, Betreff, Status, Anzahl, Child-Tickets) are hard-coded in German. Only the name of the staff entry ("Subtickets"), the title "Subticket Hierarchies" used when registering that entry, and the tooltip "%d sub-ticket(s)" go through the osTicket translation.