TickIt — Konfigurabilna platforma za tiketiranje i helpdesk
TickIt je konfigurabilna platforma za tiketiranje i helpdesk — Laravel 13 API iza Vue 3 single-page aplikacije. Administratori sami izrađuju vlastite tipove tiketa, svaki s vlastitim statusima i prilagođenim poljima, bez diranja koda; verzionirani integracijski API omogućuje drugim aplikacijama programatsko otvaranje tiketa uz idempotentan unos otporan na ponavljanja. Klijentska, agentska i administratorska uloga svaka dobiva vlastite prikaze, uz Kanban ploču, komentare u nizu, privitke datoteka i zapis aktivnosti.
TickIt je mjesto kamo aplikacije šalju svoje povratne informacije, a timovi ih obrađuju. Zanimljivi dio nije popis tiketa — već to da je tijek rada podatak, a ne kod. Tip tiketa nosi vlastite statuse i vlastita prilagođena polja, pa administrator može postaviti novu vrstu tiketa, s vlastitim pipelineom i vlastitim obrascem, a da nitko ne piše migraciju. TicketWorkflowService čita tu konfiguraciju kako bi odlučio koji su potezi dopušteni.
Druga polovica je integracijski API. Household i Chrono ne šalju izvještaje o greškama mailom — oni ih POST-aju. Taj endpoint je verzioniran i autenticiran po klijentu, te je idempotentan: ApiClientTicketService.createOrReplay() ključuje svaku predaju na Idempotency-Key, ponavlja izvorni tiket pri ponovnom pokušaju i oslanja se na jedinstveno ograničenje baze kako bi razriješio utrku kada dva ponovna pokušaja stignu istovremeno. Oko toga stoje stvari koje biste očekivali od helpdeska — Kanban ploča, komentari napisani u Tiptapu, privitci datoteka, zapis aktivnosti te web-push i mail obavijesti kada posao stigne.
Oko mehanizma tijeka rada i integracijskog API-ja stoje svakodnevni dijelovi helpdeska — projekti, dodjela tiketa, komentari, privitci i obavijesti — pa konfigurabilna jezgra i strojni unos zajedno čine alat koji se stvarno koristi iz dana u dan.
Svaki tip tiketa ima vlastiti skup statusa i vlastita prilagođena polja. Administratori definiraju tip, njegova stanja u tijeku rada i polja koja agenti popunjavaju — ništa od toga nije ugrađeno u kod. TicketWorkflowService upravlja time koji su prijelazi između statusa dopušteni.
TicketTypeField pohranjuje oznaku, tip polja, JSON blob opcija za polja tipa odabira, oznaku obaveznosti i redoslijed sortiranja — pa je novo polje redak, a ne promjena sheme. Administratorsko sučelje preuređuje redoslijed polja povlačenjem.
Verzionirani endpoint (Integrations/V1/TicketController) omogućuje vanjskim aplikacijama slanje tiketa s povratnim informacijama. Household i Chrono ga oba koriste — autenticirani po klijentu putem AuthenticateApiClient middlewarea u odnosu na ApiClient token, ograničeni na projekt.
Tiketi žive na ploči s povlačenjem na /tickets/board organiziranoj prema statusima tipa. Svaki tiket nosi komentare u nizu napisane u Tiptap editoru, privitke datoteka za prijenos i preuzimanje te potpuni zapis aktivnosti.
Kada se tiket kreira, TickIt razašilje TicketCreated obavijest preko web pusha (VAPID ključevi, push_subscriptions tablica) i mail kanala, pa agenti saznaju za novi posao bez praćenja ploče.
Klijent, agent i administrator svaki dobiva namjensko stablo prikaza. Novi projekti se pokreću iz predložaka putem ProjectSetupService, pa novi projekt dolazi sa smislenim zadanim tipovima, statusima i poljima umjesto praznog lista.
Različiti timovi žele različite oblike tiketa — različite statuse, različita polja — a isporuka migracije po zahtjevu se ne skalira.
Tijek rada modeliran je kao podatak. TicketType posjeduje svoje TicketStatus retke i TicketTypeField retke (label, field_type, JSON opcije, is_required, sort_order). Administratori slažu tipove u sučelju; TicketWorkflowService čita te podatke kako bi validirao prijelaze, pa novi tijekovi rada ne trebaju deploy.
Vanjske aplikacije ponavljaju pokušaj pri mrežnom kvaru. Naivni endpoint za kreiranje tiketa duplicirao bi tiket svaki put kada klijent ponovno pošalje isti zahtjev.
createOrReplay() ključuje svaku predaju na Idempotency-Key. Ponovljeni ključ vraća izvorni tiket umjesto da kreira drugi — čineći ponovne pokušaje sigurnima za aplikaciju koja poziva.
Dva ponovna pokušaja mogu stići dovoljno blizu da oba prođu početnu provjeru "postoji li ovaj ključ?" prije nego što ijedan izvrši commit.
Jedinstveno ograničenje na idempotency_key je izvor istine. Servis hvata kršenje jedinstvenog ograničenja pri unosu, zatim ponovno čita i vraća pobjednički tiket — pa utrku rješava baza podataka, a ne tempiranje aplikacije.
Klijenti, agenti i administratori trebaju vrlo različite površine nad istim podacima bez propuštanja međusobnih mogućnosti.
Odvojena stabla prikaza (klijent / agent / admin) na frontendu, podržana Sanctum-autenticiranim pristupom API-ju svjesnim uloga. Google OAuth pokriva ljudsku prijavu; integracijski API u potpunosti ostaje na vlastitoj putanji tokena po klijentu.