tkts
What is it?
A simple, single user oriented cli ticketing system.
Okay seriously. Why?
Because I was curious if I could. Jira service desk sucks, I personally use Zoho for both Chenmark and KlockWork Systems, but a full fledged web oriented ticketing system is too heavy for my personal use. And it isn't worth the effort to maintain something like that just to use api backends for a cli experience. tkts works well, it saves everything to a simple sqlite3 database so it can be easily rsynced between devices, and it's lua based so it'll run anywhere on anything, and if reporting functionality is lacking it can be hacked together with a little SQL.
Personally I find that far more useful than anything else I've used. You never know when you need to run some support tasks and all you have for note taking is an old droid4. That said, tkts is a work in progress and likely to change as I get time to improve it.
Usage Overview
Currently tkts supports namespaced arguments, it's inefficient and confusing, but operable. There's an issue open on the git repo to address inconsistencies and functionality issues of this design and it will be rewritten from scratch in the near future.
~|>> tkts -h
;;===== Usage =====
[-o issue ?desc] [-c tnum] [-r tnum] [-e tnum] [-al tnum ?log] [-m tnum] [-t tnum ?time] [-s ?status]
log [-e tnum rnum]
company [-a name] [-e name] [-li] [-i name]
client [-a name company] [-e name company] [-li] [-i name company]
help [-h] [-v]
Tkts Namespace:
tkts | Show currently opened tickets
tkts -o "new issue" | Open a ticket
tkts -o "new issue" "desc" | Open a ticket with a description
tkts -c T# | Close a ticket
tkts -r T# | Reopen a ticket
tkts -al T# | Add a log to the ticket via editor
tkts -al T# "log info to ticket" | Add a log to the ticket via string
tkts -m T# | Send email to client defined in specified ticket
tkts -t T# | Add logging to ticket via editor, while recording time spent
tkts -t T# # | Add time to the ticket
tkts -i T# ?-v | Return ticket information, -v for full log
tkts -e T# | Editan existing ticket's data
tkts -s [open,closed,all] ?-v | Report tickets by status, -v for info
Log Namespace:
tkts log -e T# R# | Edit a specified log in a tkt
Company Namespace:
tkts company -a "name" "short" | Add a new company
tkts company -e "name" | Edit an existing company
tkts company -li | List all companies
tkts company -i "name" | Show company details
Client Namespace:
tkts client -a "name" "company" | Add a client, associated with company
tkts client -e "name" "company" | Edit an existing client
tkts client -li | List all clients
tkts client -i "name" "company" | Show client details
Usage Examples
Invoked by itself tkts will return an Open ticket list, these are the users active and in progress tickets. If an issue is not completed it's considered open. tkts is designed with this simple boolean style state to prevent over complication. If you're still working on something it'll be there. If your tickets appear to languish using this system my best advice is to break larger projects into smaller ones and close each in accord. tkts does not currently support subtasks, or association with a parent task, but if someone would like that feature please open an issue on the repo on Gitlab.
Open: 7 | Closed: 4 Open Tickets: T2) [H] - Organize Photos on NAS T3) [H] - Cleanup Data on NAS T5) [H] - NAS critical docs cloud backup T6) [A] - Package Gemini Server & Client T7) [LC] - Add TLS Cert to LambdaCreate T8) [LC] - Rewrite RSS Feed Generator T9) [LC] - Rewrite LambdaCreate
Each ticket contains an issue title, status, owner, client, project, description, time tracking, and log table. Inspecting a ticket with tkts -i # shows a brief overview of these values. Log is hidden by default.
~|>> tkts -i 4
Issue: [H] - Fix APK CI/CD
Status: Open | Owner: durrendal
Client: Mio | Proj: Casa Repo
Desc:
Issues with artifacts & MRs
Time: 362min ($272)
Log: 3
Disclaimer: monetary values shown here are purely for example, nobody was charged for this project.
Issues and descriptions are free form text, I opt for a bracketed abbreviation character - title for my issues. For example I use [A] for alpine packages/issues, [H] for home tasks, and [W] for work related things. However anything can be used that makes sense to the end user.
Time is recording in minutes, adding tkts -t 1 5 would add 5 minutes to tkt 1. If you define an hourly rate in your .tkts configuration file tkts will automatically convert time into billable amounts. By default tkts rounds up to the next full minute. Additionally each comment in a ticket contains an owner and time value so that total time records can be matched with the work performed.
~|>> tkts -i 4 -v
Issue: [H] - Fix APK CI/CD
Status: Open | Owner: durrendal
Client: Mio | Proj: Casa Repo
Desc:
Issues with artifacts & MRs
Time: 362min ($272)
1) {durrendal, 62}
After doing some testing with Mio the following issues were discovered:
> MRs do not properly queue jobs (they tag as alpine but do not find runners.)
> Artificats cannot be downloaded from finished runners
Will need to stop and address both of these issues before they're useable for others.
2) {durrendal, 120}
Setup the rockpro as a glab runner, it's not using lxc or anything, just running by itself. It seems to work when you make MRs, it'll queue the jobs at least.
Either the containers need to be rebuilt (probably), or there's an issue with the hwclock (there definitely is) because the test CI/CD jobs failed due to timeout errors, and zabbix threw nasty out of sync errors during the CI jobs, all three arm jobs queued, ran, and then failed with the same curl SSL cert error.
3) {durrendal, 180}
Wrote PNTP, a poorman's NTP server. The hwclock on the rockpro slips by hours consistently, and occasionally by years forwards and backwards seemingly randomly.
PNTP exposes a simple REST interface so that a properly synced client can provide an accurate NTP based time, and a simple client script run via a cronjob force syncs the clock every 15 minutes. This appears to resolve most of the build issues.
Additional problems occured with package update slippage. Another tweak to the CI/CD setup after implementing PNTP has us rebuilding our apkbuild containers nightly, which appears to negate those issues as well.
Modifiying and recording time in an ad hoc way is currently very clunky You can add a comment to a tkt with tkts -al #, which will open your $EDITOR, but it won't record time. You can add total time manually with tkts -t # time, but it won't associate with a record. Right now the best workflow I have is tkts -t 1, which will open an $EDITOR and track the time that editor is open, assumption being that you're working and recording comments in the editor as you work. This automatically adds record time and total time. If this gets out of sync though you'll currently need to modify the tkt manually and insert the total time you get from a simple sql query. Here let me show you.
Lets assume that the time spent on record 1 in tkt 4 was actually 42 minutes instead of 62.
~|>> tkts log -e 4 1
Running the edit function in the log workspace returns a lua table of editable values.
{
log = "After doing some testing with Mio the following issues were discovered:\n\n> MRs do not properly queue jobs (they tag as alpine but do not find runners.)\n> Artificats cannot be downloaded from finished runners\n\nWill need to stop and address both of these issues before they're useable for others.",
time = 62,
user = "durrendal"
}
Modifying time = 62, to time = 42, and then saving and exiting the file will update the tkt and return the modified log.
Total time isn't updated though for that, jump into the tkts.db
sqlite3 ~/.config/tkts/tkts.db
select um(time) from records where tkt_num =4:
342
Now that we have the correct time, we need to edit the tkt's data.
~|>> tkts -e 4
{
client = "Mio",
desc = "Issues with artifacts & MRs",
owner = "durrendal",
project = "Casa Repo",
status = "Open",
time = 362,
title = "[H] - Fix APK CI/CD"
}
And once more, set time = 342, save and exit, and your tkt will reflect the proper time again.
Boy that seems convoluted, but there's at least a process, and tkts is built on top of well documented and robust open source systems which let anyone hac their way around problems. As I fix the issues with the cli arguments for tkts I'll be adding a better method to track this, likely by simply causing the edit function to reconcile the issue automatically. Pain points like this one have come up as I've continued to use tkts for more and more of my own house keeping.