mosaicstack/stack
16
0
Fork 1
Code Issues 330 Pull Requests 12 Actions Packages Projects Releases 15 Wiki Activity

glpi/ticket-create.sh: support parent/child ticket linkage (-P) for hierarchical audit trails #885

New Issue
Open
opened 2026-07-24 16:38:45 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-07-24 16:38:45 +00:00
Owner
Copy Link
Copy Source

Summary

tools/glpi/ticket-create.sh can create a ticket and (since the requester change) attach a
requester, but it cannot establish a link between tickets — in particular a parent/child
(hierarchy) relationship. GLPI models this with the Ticket_Ticket resource
(tickets_id_1, tickets_id_2, link), where link: 3 = "son of" and link: 4 = "parent of".
Any workflow that wants an umbrella/parent ticket with child tickets under it (project → tasks,
incident → sub-tasks, epic → work items) has to drop out of the wrapper and POST to
/Ticket_Ticket by hand.

Motivation

Building an ITSM audit trail on top of an external system-of-record frequently means one parent
ticket per initiative and one child ticket per discrete unit of work, linked so the hierarchy is
visible in GLPI. Today the wrapper gets you the tickets but not the linkage, so every operator
re-implements the same raw-curl Ticket_Ticket call — and those local patches are wiped on every
mosaic upgrade.

Proposed change

Add a -P <parent_ticket_id> option to ticket-create.sh that, after the new ticket is created,
POSTs Ticket_Ticket {input:{tickets_id_1:<new>, tickets_id_2:<parent>, link:3}} to link the new
ticket as a child ("son of") the given parent.

  • -P accepts a numeric ticket id.
  • Link is created after successful ticket creation; a failed link warns (with HTTP code) but
    does not fail the run — the ticket already exists.
  • -f json output gains a link_status field.
  • Back-compatible: omitting -P changes nothing.

Optionally, a more general -L <type>:<ticket_id> could expose all four GLPI link types
(1=link, 2=duplicate, 3=son, 4=parent), but child-of-parent is the priority gap.

Acceptance criteria

  • ticket-create.sh ... -P <id> creates the ticket and links it as child of <id>.
  • The link is visible in GLPI on both tickets (parent shows the child, child shows the parent).
  • A failed link warns but the ticket still succeeds (link is best-effort post-create).
  • -h help documents -P.
  • -f json includes link_status.

Notes

Ticket_Ticket link legend: 1=Link, 2=Duplicate, 3=Son of, 4=Parent of. Reference
implementation (raw POST) has been validated against a live GLPI instance creating 17
parent/child links in one batch with zero failures.

## Summary `tools/glpi/ticket-create.sh` can create a ticket and (since the requester change) attach a requester, but it cannot establish a **link between tickets** — in particular a parent/child (hierarchy) relationship. GLPI models this with the `Ticket_Ticket` resource (`tickets_id_1`, `tickets_id_2`, `link`), where `link: 3` = "son of" and `link: 4` = "parent of". Any workflow that wants an umbrella/parent ticket with child tickets under it (project → tasks, incident → sub-tasks, epic → work items) has to drop out of the wrapper and POST to `/Ticket_Ticket` by hand. ## Motivation Building an ITSM audit trail on top of an external system-of-record frequently means one parent ticket per initiative and one child ticket per discrete unit of work, linked so the hierarchy is visible in GLPI. Today the wrapper gets you the tickets but not the linkage, so every operator re-implements the same raw-curl `Ticket_Ticket` call — and those local patches are wiped on every `mosaic` upgrade. ## Proposed change Add a `-P <parent_ticket_id>` option to `ticket-create.sh` that, after the new ticket is created, POSTs `Ticket_Ticket {input:{tickets_id_1:<new>, tickets_id_2:<parent>, link:3}}` to link the new ticket as a child ("son of") the given parent. - `-P` accepts a numeric ticket id. - Link is created **after** successful ticket creation; a failed link warns (with HTTP code) but does not fail the run — the ticket already exists. - `-f json` output gains a `link_status` field. - Back-compatible: omitting `-P` changes nothing. Optionally, a more general `-L <type>:<ticket_id>` could expose all four GLPI link types (`1`=link, `2`=duplicate, `3`=son, `4`=parent), but child-of-parent is the priority gap. ## Acceptance criteria - [ ] `ticket-create.sh ... -P <id>` creates the ticket and links it as child of `<id>`. - [ ] The link is visible in GLPI on both tickets (parent shows the child, child shows the parent). - [ ] A failed link warns but the ticket still succeeds (link is best-effort post-create). - [ ] `-h` help documents `-P`. - [ ] `-f json` includes `link_status`. ## Notes `Ticket_Ticket` link legend: `1`=Link, `2`=Duplicate, `3`=Son of, `4`=Parent of. Reference implementation (raw POST) has been validated against a live GLPI instance creating 17 parent/child links in one batch with zero failures.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-infra-01 (Mosaic fleet seat code-infra-01) fargo fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) merge-gate ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) pepper rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) sanity scooby (Scooby) scrappy shaggy tiny velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#885