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 single static file so it can be easily rsynced between devices, and it's lua based so it'll run anywhere on anything.
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, ticket comments are currently what I would describe a kludgey, and would benefit highly from launching a real editor instead of relying on passing strings as args.
;;===== tkts v1.3.0 ===== Author: Will Sinatra
License: GPLv3 ;;===== Usage ===== usage: [-o issue ?desc] [-c tnum] [-al tnum ?note] [-t tnum time] edit: [-e tnum] info: [-i tnum] [-r ?type ?-v] [--dissolve] tkts -o "new issue" | Open a ticket tkts -o "new issue" "desc" | Open a ticket with a description tkts -c T# | Close the 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 -t T# # | Add time to the ticket tkts -i T# | Return information about the ticket tkts -e T# | Edit the ticket's data table tkts -r [open,closed,all] ?-v | Report tickets by status, -v for info tkts arg -v | Increase verbosity of arg tkts --dissolve | Delete all ticketing information
By default tkts only returns opened tickets, however a full open/closed report can be generated. The output is exactly the same as below, only missing the closed segment. The report option additionally supports a verbosity flag which will return the information contents of every ticket of the specified status.
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 Closed Tickets: T1) [H] - Hardwire NAS to Mikrotik Lab T4) [H] - Investigate NFS share for NAS T10) [A] - Package Inform 7 T11) [A] - Package TTY Solitaire
Each ticket contains a issue title, description, time tracking, and log table.
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 a two decimal float integer. I typically track this as hours (1.0 = 60min), but it could be used to track in hour segments. By design I feel 140.00 minutes is easier to deal with than .33 hours. And tkts -t flag operates with that in mind. tkts -t 10 would add ten minutes, or if you want tkts -t .33 would add 1/3 an hour. But it's arbitrary flat math, not calculated. So if you mix 10 & .33 you get 10.33 not 30.
Finally the log table is exactly that, it's an ordered lua table of strings. When adding a log to a ticket users only need to provide a T# which will launch a text editor. Each line in that editor will correspond to a line in the log table. You can additionally just pass a string as an additional arg if you need to make a one off comment.
All of these values can be updated with the -e flags, which will cherry pick the data table of the provided t# and load it in a text editor. This provides a raw lua table for the user to edit, but they can make changes to anything within the data structure of the ticket.
Issue: [A] - Package Inform 7 Desc: Lucidiot requested Status: closed Time: 140.0 Log: 1) https://github.com/ptomato/gnome-inform7 2) toAPK conversion covered most things, but the source url required a special var 3) install script had to be patched to allow armv7 to pull armv6hf sources, dunno if that'll work long term 4) apkbuild needed !strip, plus a sed arg to set the library path 5) Fixed the issue, needed to have two separate patches, one for armv7 and one for /usr as a prefix. Package seems set. Checking with lucid to see if there's anything other than the cli 6) Submitted MR !14613 upstreamed, needed additional patches for armv8l 7) Package refused because it ships non-open source binaries without source code. 8) If source is GPL and obtainable then it can be shipped otherwise alpine refuses. Lucid is okay using an unofficial package, so I'll get that to him.
I'm constantly trying to improve tkts by adding little features. And I'm actively using it to maintain contracts and FOSS projects I'm working on/with. For example I've recently added rate tracking for hourly billing, such that you can get an estimate of labour spent in cost. And I've begun document the data API so that I can provide a read only web portal, with plans to extend this to web app support and a multiuser mode.
If you'd like to contact me about my software, ponderings, or just to chat; you can reach me at firstname.lastname@example.org
"Very little indeed is needed to live a happy life." - Aurelius
- This Distro is Not For You
- Low Spec Computers
- MikroTik Maplite Magic
- Lisp, Make, & Esper
- Building Blocks
- Decentralized Collaboration
- Mobile Workflow: Part 2
- Striving Towards Happiness
- Building an Alpine NAS
- Did I Make Enough Static?
- Macros in Fennel
- Emulating aarch64
- Fennel Confusion
- toAPK -v template
- Mobile Workflow
- Tying up loose ends
- toAPK chez-scheme
- OpenRC & Open Source
- My Docker Workflow
- Over-Engineering a Blog: Part 2
- Over-Engineering a Blog: Part 1
- About Lambda Create