Skill: glpi-list — Query GLPI Tickets

Quick lookups of GLPI helpdesk tickets by status or recency. Read-only.

When to use

"What tickets are open / pending?" · "Show recent tickets" · finding a ticket ID before running glpi-followup or glpi-solve.

Command

Wraps the existing tooling:

GLPI=~/.config/mosaic/tools/glpi

# Most recent tickets (default 50, newest first)
"$GLPI/ticket-list.sh"

# Filter by status: new | processing | pending | solved | closed
"$GLPI/ticket-list.sh" -s pending

# JSON output (for parsing / piping to jq) and a custom limit
"$GLPI/ticket-list.sh" -s processing -f json -l 20

Status IDs: 1 New · 2/3 Processing · 4 Pending · 5 Solved · 6 Closed.

Details lookup for one ticket

When you have an ID and want the full record:

SESSION=$(~/.config/mosaic/tools/glpi/session-init.sh -q)
source ~/.config/mosaic/tools/_lib/credentials.sh && load_credentials glpi
curl -sk "${GLPI_URL}/Ticket/<id>?expand_dropdowns=true" \
  -H "App-Token: $GLPI_APP_TOKEN" -H "Session-Token: $SESSION" \
  | jq '{id, name, status, date, date_mod}'

# Followups on a ticket
curl -sk "${GLPI_URL}/Ticket/<id>/ITILFollowup" \
  -H "App-Token: $GLPI_APP_TOKEN" -H "Session-Token: $SESSION" \
  | jq '.[] | {date, content}'

(Reading followups via the sub-resource is fine — only creating them requires the top-level /ITILFollowup endpoint. See glpi-followup.)

Present to user

Group by status, one line per ticket: #<id> · <title> · <status> · <last-modified>. Use neutral phrasing — no "OVERDUE"/"URGENT".

Guardrails

Read-only. Never echo GLPI tokens.
To sync tickets into brain data instead, use python tools/sync_glpi.py (not this skill).

1.7 KiB Raw Permalink Blame History