Co nowego: - Kolumny kolejki operatora: dwie nowe (ID, e-mail) obok istniejących, oraz możliwość zmiany kolejności widocznych kolumn strzałkami ↑/↓ w picker „Kolumny” — nie tylko włączanie/wyłączanie. Kolejność zapamiętywana jest per operator tak samo jak dotąd widoczność. - Wybór sprzętu klienta (Snipe-IT): druga lista dozwolonych kategorii obok istniejącej listy podkategorii — pozwala objąć od razu wszystkie podkategorie danej kategorii jednym zaznaczeniem. - Pulpit klienta i widok zgłoszenia operatora pamiętają teraz aktywną zakładkę, więc „Wróć do listy” wraca do tej samej, a nie zawsze do domyślnej. Poprawki: - Paginacja (kolejka operatora, pulpit klienta) używała domyślnego, szarego stylu Laravela reagującego na motyw systemu/przeglądarki, a nie przełącznik jasny/ciemny w aplikacji — stąd ciemne przyciski nawet w trybie jasnym. Podmieniony na własny widok zgodny z kolorami aplikacji (w tym własne tło/border każdego przycisku i wyśrodkowanie na telefonie). - Kolorystyka boksu z informacją o logowaniu nie zmienia już odcienia między trybem jasnym i ciemnym (wcześniej pochodziła z --color-accent) — teraz stałe, ciemne tło w obu trybach, więc kolory tekstu ustawione przez admina (np. biały) zostają czytelne niezależnie od motywu. Poszerzona karta logowania (380px → 480px). - Lista zgłoszeń klienta: etykiety priorytetu/statusu nie zawijają się już do osobnej linii przy długim temacie na wąskich ekranach — zostają przypięte do prawej, a temat zawija się we własnej kolumnie. - Liczniki czasu pracy (resumeTimer/stopTimer/...) nie dotykają już updated_at — samo otwarcie zgłoszenia nie liczy się jako aktualizacja. Kolejka operatora i pulpit klienta domyślnie sortują po dacie utworzenia z tego samego powodu. Zaktualizowana dokumentacja: README, CLAUDE.md, ARCHITECTURE.md, CHANGELOG.md, wiki/admin, wiki/client, wiki/operator. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
378 lines
23 KiB
Markdown
378 lines
23 KiB
Markdown
# Przewodnik — Administrator
|
||
|
||
Panel administratora (`/admin`) to jedno miejsce do konfiguracji całego systemu:
|
||
struktura zgłoszeń (kategorie, pola, statusy, priorytety, SLA), automatyzacje
|
||
(reguły SLA, wyzwalacze, automatyzacja AI zgłoszeń), użytkownicy i zespoły,
|
||
treści (szablony, szybkie akcje, e-maile), wygląd/branding oraz integracje
|
||
(LDAP, poczta SMTP/IMAP, BookStack, AI, API).
|
||
|
||
Domyślnie każde konto ląduje po zalogowaniu w panelu Klienta; przełącz się do
|
||
panelu Administratora suwakiem Klient/Operator/Administrator na środku
|
||
górnego paska.
|
||
|
||
## Kategorie i pola dodatkowe
|
||
|
||
- **Kategorie / podkategorie** — nazwa + opis (widoczny klientowi przy wyborze).
|
||
Podkategoria może mieć **domyślny priorytet**, nadawany automatycznie nowym
|
||
zgłoszeniom w tej podkategorii.
|
||
- **Pola dodatkowe** (custom fields) — typ (tekst / tekst długi / lista wyboru /
|
||
checkbox / data / liczba), czy wymagane, opcje (dla listy wyboru). Każde pole
|
||
przypisuje się do jednej lub wielu podkategorii z określoną kolejnością
|
||
wyświetlania — te pola pojawiają się klientowi w formularzu zgłoszenia i
|
||
operatorowi w widoku zgłoszenia.
|
||
|
||
## Użytkownicy
|
||
|
||
- Lista użytkowników z rolami (**Klient / Operator / Administrator** — konto może
|
||
mieć więcej niż jedną). Rola nadaje dostęp do odpowiedniego panelu.
|
||
- **Pola użytkownika** — analogicznie do pól zgłoszenia, ale dla profilu
|
||
użytkownika (np. Stanowisko, Dział, Firma, telefon) — mogą być mapowane na
|
||
atrybut LDAP (`ldap_attribute`), żeby wypełniały się automatycznie przy
|
||
synchronizacji z katalogiem.
|
||
- **Synchronizuj z LDAP** — ręczne wymuszenie ponownej synchronizacji kont z
|
||
katalogu (poza standardowym sync-on-login).
|
||
- Konta lokalne (utworzone tu, z hasłem) logują się przez fallback e-mail +
|
||
hasło lokalne, gdy dopasowanie po LDAP-owym atrybucie loginu się nie powiedzie
|
||
— tak działa domyślne konto awaryjne `admin@example.com`.
|
||
|
||
## Zespoły
|
||
|
||
Każdy zespół ma listę **członków** (operatorów) i listę **podkategorii**, za
|
||
które odpowiada. Gdy w Konfiguracji włączone jest „automatyczne przypisywanie wg
|
||
kategorii”, nowe zgłoszenie w danej podkategorii trafia od razu do właściwego
|
||
zespołu. Operator spoza zespołu nie widzi jego kolejki (poza zgłoszeniami bez
|
||
zespołu i przypisanymi mu bezpośrednio).
|
||
|
||
## Statusy, priorytety i SLA
|
||
|
||
- **Statusy** mają trzy stałe etapy (`stage`): `new`, `open`, `closed`. Statusy
|
||
„Nowe”, „Otwarty” i „Zamknięte” są zablokowane (`locked`) i nie można ich
|
||
usunąć — pozostałe (W trakcie, Oczekuje na klienta, itd.) są w pełni
|
||
edytowalne/usuwalne dowolnie w ramach etapu „open”. Każdy status ma nazwę,
|
||
kolor i kolejność wyświetlania.
|
||
- **Priorytety** — nazwa, kolor, kolejność.
|
||
- **SLA** — dla każdego priorytetu: czas do pierwszej odpowiedzi (`response_mins`)
|
||
i czas do rozwiązania (`resolution_mins`), w minutach. Priorytet z czasem
|
||
rozwiązania = 0 nigdy nie jest liczony jako naruszenie SLA (np. priorytet
|
||
„Brak”). Naruszenia sprawdza cykliczne zadanie co 15 minut
|
||
(`tickets:check-sla-breaches`) i może powiadomić operatora.
|
||
|
||
## Automatyzacja SLA
|
||
|
||
Reguły, które same zmieniają zgłoszenie po określonym czasie **ciszy ze strony
|
||
klienta** (liczonym od ostatniej odpowiedzi klienta, a jeśli jeszcze nie
|
||
odpowiedział — od utworzenia zgłoszenia). Każda reguła ma:
|
||
|
||
- **Nazwę** i przełącznik **aktywna/nieaktywna**.
|
||
- **Próg** w minutach.
|
||
- Opcjonalne **zawężenie** — priorytet / kategoria (podkategoria) / zespół;
|
||
puste pole = dowolny. Wszystkie warunki muszą być spełnione naraz.
|
||
- **Akcję** — zmień priorytet / status / zespół / przypisanego operatora, oraz
|
||
wartość docelową.
|
||
|
||
Reguły sprawdza cykliczne zadanie co 15 minut (`automation:run-rules`, razem z
|
||
`tickets:check-sla-breaches`). Akcja korzysta z tych samych mechanizmów co
|
||
ręczna zmiana przez operatora — dostaje wpis w historii zgłoszenia (z dopiskiem
|
||
„Automatyzacja: nazwa reguły”), wysyła standardowe powiadomienie dla tej zmiany
|
||
i pojawia się na żywo w kolejce/widoku zgłoszenia. Reguła nie powtarza się dla
|
||
tego samego zgłoszenia, dopóki klient znów nie napisze albo zgłoszenie nie
|
||
zostanie zamknięte i otwarte ponownie — więc bezpiecznie zostawić kilka
|
||
aktywnych reguł naraz, bez ryzyka zapętlenia się co 15 minut.
|
||
|
||
## Wyzwalacze
|
||
|
||
W odróżnieniu od Automatyzacji SLA (działa po czasie ciszy klienta), wyzwalacze
|
||
reagują **natychmiast** na zdarzenie w zgłoszeniu: utworzenie, dowolna zmiana
|
||
pola, zmiana statusu/priorytetu/przypisania/zespołu/kategorii, nowa wiadomość
|
||
publiczna. Każdy wyzwalacz ma:
|
||
|
||
- **Zdarzenie**, na które reaguje.
|
||
- **Warunki** (opcjonalne, wszystkie muszą być spełnione naraz — ORAZ) na polu
|
||
statusu, priorytetu, zespołu, podkategorii, zgłaszającego, tematu lub treści.
|
||
- **Akcje** wykonywane po kolei — ustaw status/priorytet/zespół/operatora, albo
|
||
wyślij powiadomienie e-mail do zgłaszającego lub przypisanego operatora.
|
||
|
||
Akcja „Wyślij powiadomienie e-mail” korzysta z **własnych szablonów wyzwalaczy**
|
||
(sekcja „Szablony e-mail wyzwalaczy” na tej samej zakładce) — w pełni
|
||
dodawalnych/edytowalnych/usuwalnych przez administratora, celowo osobnych od
|
||
stałych szablonów opisanych niżej (te są przypisane 1:1 do zdarzeń systemowych
|
||
i nie da się ich usunąć ani dodać nowego). Wyzwalacz może zmienić to samo pole,
|
||
które sam sprawdza w warunku — zabezpieczenie przed zapętleniem: akcja, która
|
||
tylko potwierdzałaby już ustawioną wartość, nic nie robi, a licznik głębokości
|
||
zatrzymuje prawdziwy cykl między dwoma wyzwalaczami.
|
||
|
||
## Szybkie akcje odpowiedzi
|
||
|
||
Przyciski w widoku zgłoszenia operatora, które **wysyłają odpowiedź i od razu
|
||
zmieniają status** (np. „Wyślij i zamknij”) — konfigurowalne: etykieta, docelowy
|
||
status, kolejność. Status jest tu „miękkim” odniesieniem (po kluczu) — usunięcie
|
||
statusu w Admin nie usuwa powiązanej z nim szybkiej akcji, po prostu przestaje
|
||
zmieniać status.
|
||
|
||
## Szablony odpowiedzi
|
||
|
||
Gotowe teksty (zwykły tekst, bez HTML — pole odpowiedzi w kolejce to zwykły
|
||
`<textarea>`) do szybkiego wstawienia w odpowiedzi operatora, np. „Prośba o
|
||
więcej informacji”, „Restart usuwa problem”.
|
||
|
||
## Szablony e-mail i powiadomienia
|
||
|
||
- **Szablony e-mail** — treść **HTML** (nagłówki `<p>`, linki jako `<a href="{link}">`,
|
||
itd. — nie zwykły tekst z `\n`, bo trafia bezpośrednio do maila jako markup) z
|
||
placeholderami: `{numer}`, `{imie}`, `{temat}`, `{status}`, `{kategoria}`,
|
||
`{priorytet}`, `{zespol}`, `{operator}`, `{link}`. Każdy szablon opakowuje się
|
||
automatycznie we wspólny layout (nagłówek z nazwą firmy + stopka — patrz niżej).
|
||
Te szablony są przypisane **na stałe** do zdarzeń systemowych (nie da się ich
|
||
dodać/usunąć/przepiąć na inne zdarzenie) — dla wyzwalaczy (zakładka
|
||
Wyzwalacze) służy osobny, w pełni dowolny zestaw szablonów, opisany wyżej.
|
||
- **Stopka e-mail** i **layout HTML** — stopka jest edytowalna (z przyciskiem
|
||
„Resetuj” do wartości domyślnej); sam layout nie jest edytowalny z poziomu UI.
|
||
- **Powiadomienia** — lista zdarzeń (zgłoszenie utworzone, zmiana statusu/
|
||
kategorii/priorytetu/zespołu/przypisania, zgłoszenie zamknięte, operator
|
||
odpowiedział, SLA przekroczone, **nowe zgłoszenie w zespole**) — każde ma
|
||
przełącznik włącz/wyłącz, odbiorcę (klient / operator) i przypisany szablon.
|
||
Usunięcie przypisanego szablonu po prostu wyłącza wysyłkę tego powiadomienia,
|
||
dopóki ktoś nie wybierze nowego. „Zmiana statusu” i „zgłoszenie zamknięte” się
|
||
wzajemnie wykluczają dla tej samej zmiany — zamknięcie zgłoszenia wysyła
|
||
wyłącznie powiadomienie „zgłoszenie zamknięte”, żeby nie dublować maila.
|
||
„Nowe zgłoszenie w zespole” (domyślnie włączone) trafia do **każdego**
|
||
operatora w zespole, którego podkategorie pasują do nowego zgłoszenia, nie
|
||
tylko do jednej przypisanej osoby. **Ten sam przełącznik kontroluje zarówno
|
||
e-mail, jak i powiadomienie w dzwoneczku w aplikacji** — nie ma osobnego
|
||
ustawienia dla powiadomień w apce, a dzwoneczek pokazuje tylko nieprzeczytane
|
||
(znikają po kliknięciu/oznaczeniu) i aktualizuje się na żywo.
|
||
- **Preferencje powiadomień per operator/admin** (`/settings/notifications`,
|
||
menu profilu → „Powiadomienia”) — każdy sam wybiera, dla nowego zgłoszenia/
|
||
aktualizacji/eskalacji, jaki zakres zgłoszeń (moje / nieprzypisane /
|
||
obserwowane / wszystkie) ma go powiadamiać dzwoneczkiem i czy dodatkowo
|
||
e-mailem, plus opcjonalne natywne powiadomienia push przeglądarki. To
|
||
ustawienie jest niezależne od globalnego przełącznika powiadomień opisanego
|
||
wyżej — dotyczy dodatkowego powiadamiania innych operatorów/adminów o
|
||
zgłoszeniach w ich zakresie, nie zastępuje go.
|
||
|
||
## Wygląd / Branding
|
||
|
||
Nazwa firmy, logo, favicon, kolor akcentu (motyw jasny/ciemny podąża za nim),
|
||
oraz **komunikat na stronie logowania** (typ: informacja/ostrzeżenie/sukces/
|
||
ważne + treść HTML).
|
||
|
||
## Konfiguracja
|
||
|
||
- **Ogólne** — domyślny status nowego zgłoszenia, automatyczne przypisywanie wg
|
||
kategorii, limity załączników (rozmiar/liczba/typy), czas życia sesji, strefa
|
||
czasowa.
|
||
- **Numeracja zgłoszeń** — dowolny **prefiks** numeru (domyślnie `#`) i
|
||
**minimalna długość** (dopełniana zerami z przodu, dotyczy tylko trybu
|
||
sekwencyjnego). Checkbox **„Ukryj kolejność zgłoszeń”** przełącza
|
||
wyświetlany numer z kolejnego (np. `#1042`) na stałą, losowo wyglądającą
|
||
**sumę kontrolną** (np. `#559122`) przypisaną zgłoszeniu raz, na zawsze —
|
||
tak, by po samym numerze nie dało się odgadnąć, ile jest zgłoszeń ani w
|
||
jakiej kolejności powstały. Podgląd pod polami pokazuje na żywo, jak
|
||
będzie wyglądał numer dla realnego zgłoszenia z bazy, zanim się zapisze
|
||
zmiany. Gdy ta opcja jest włączona, **linki do zgłoszeń też** posługują
|
||
się sumą kontrolną zamiast kolejnego numeru — stary link ze zwykłym
|
||
numerem przestaje działać. REST API (`/api/v1/...`) tego nie dotyczy —
|
||
tam zgłoszenia zawsze identyfikuje się po `id`, niezależnie od tego
|
||
ustawienia.
|
||
- **Częstotliwość odświeżania i harmonogramu** — dwie grupy pól:
|
||
- **Odświeżanie w przeglądarce** — co ile sekund odświeża się (poza
|
||
aktualizacjami na żywo) widok zgłoszenia (klient i operator), lista
|
||
zgłoszeń operatora, i dzwonek powiadomień.
|
||
- **Zadania w tle** — co ile minut uruchamiają się sprawdzanie naruszeń
|
||
SLA, reguły automatyzacji, pobieranie e-maili (IMAP) i automatyzacja AI
|
||
zgłoszeń. Zmiana obowiązuje od najbliższego tyknięcia harmonogramu (co
|
||
minutę), bez potrzeby restartu czy redeployu.
|
||
|
||
SMTP (host, port, szyfrowanie, użytkownik/hasło, adres/nazwa nadawcy, z
|
||
przyciskiem **„Testuj połączenie”**) konfiguruje się w zakładce **Poczta**,
|
||
razem z layoutem/stopką wiadomości i skrzynkami IMAP (patrz niżej).
|
||
|
||
## Poczta — odbieranie zgłoszeń i odpowiedzi e-mailem (IMAP)
|
||
|
||
Zakładka **Poczta** (dawniej „E-MAIL") łączy konfigurację SMTP (wysyłka) ze
|
||
skrzynkami IMAP (odbiór) — obie strony wymiany e-mailowej z klientem żyją
|
||
razem, zamiast być rozrzucone po różnych zakładkach.
|
||
|
||
- **Wiele skrzynek IMAP jednocześnie** — np. `zgloszenia-it@firma.pl` i
|
||
`zgloszenia-hr@firma.pl` jako dwie osobne, niezależnie włączane skrzynki,
|
||
każda z własnym hostem/portem/szyfrowaniem/loginem/hasłem i folderem.
|
||
- **Cel nowych zgłoszeń** — jeden wspólny selektor pozwala wybrać albo
|
||
**konkretną podkategorię** (trafi też do jej zespołu, tak jak zgłoszenie
|
||
założone przez formularz web), albo **całą kategorię** bez wskazywania
|
||
podkategorii (zgłoszenie zostaje nieprzypisane do zespołu, ale kategoria
|
||
jest widoczna i można po niej filtrować kolejkę operatora), albo zostawić
|
||
puste (zgłoszenie całkiem nieprzypisane).
|
||
- **Dopasowywanie odpowiedzi** — odpowiedź na powiadomienie e-mail (temat
|
||
zawiera numer/sumę kontrolną zgłoszenia) trafia jako kolejna wiadomość do
|
||
tego samego wątku, nie jako nowe zgłoszenie — widoczna na żywo u operatora,
|
||
tak jak każda inna odpowiedź.
|
||
- **Filtry przed śmieciowymi zgłoszeniami** — automatyczne odpowiedzi
|
||
(autorespondery, „poza biurem”, bounce/mailer-daemon) są rozpoznawane po
|
||
nagłówkach (`Auto-Submitted`, `Precedence`) i typowych frazach w temacie
|
||
(PL i EN) i **odrzucane bez tworzenia zgłoszenia**; dodatkowa lista
|
||
zablokowanych nadawców per skrzynka (domyślnie `mailer-daemon, postmaster,
|
||
no-reply, noreply`).
|
||
- **„Tylko użytkownicy z LDAP”** (Integracje → LDAP) działa identycznie dla
|
||
poczty jak dla formularza gościa na stronie głównej — jeśli włączone, e-mail
|
||
od nieznanego nadawcy (spoza LDAP i bez lokalnego konta) jest odrzucany, nie
|
||
tworzy zgłoszenia.
|
||
- **Folder po przetworzeniu / folder odrzuconych** (opcjonalnie) — jeśli
|
||
puste, wiadomość zostaje na miejscu tylko oznaczona jako przeczytana.
|
||
- **Przycisk „Pobierz teraz”** przy każdej skrzynce — ręczne, natychmiastowe
|
||
sprawdzenie poczty bez czekania na harmonogram (co 5 minut), działa też dla
|
||
wyłączonej skrzynki; pokazuje od razu liczbę nowych/odpowiedzi/odrzuconych/
|
||
błędów.
|
||
- **Przycisk „Testuj połączenie”** sprawdza niezapisane wartości formularza,
|
||
bez zapisywania.
|
||
- **Log** — cała aktywność (połączenia, każda decyzja per wiadomość, błędy)
|
||
trafia do osobnego pliku `storage/logs/imap-*.log`, niezależnie od
|
||
ogólnego poziomu logowania aplikacji — najlepsze miejsce do sprawdzenia,
|
||
dlaczego dany e-mail się nie przetworzył.
|
||
- **Znacznik „e-mail"** — zgłoszenie i pojedyncze wiadomości utworzone z
|
||
poczty mają widoczną ikonę koperty w kolejce operatora i w widoku
|
||
zgłoszenia, odróżniając je od zgłoszeń/odpowiedzi z formularza web.
|
||
|
||
> Sprawdzanie skrzynek działa cyklicznie tylko wtedy, gdy na serwerze jest
|
||
> skonfigurowany zewnętrzny cron wywołujący `php artisan schedule:run` (patrz
|
||
> [install.md](../../install.md)) — bez tego działa wyłącznie przycisk
|
||
> „Pobierz teraz”.
|
||
|
||
## Integracje
|
||
|
||
- **LDAP** — **Typ katalogu** (LLDAP/OpenLDAP domyślnie, albo Active
|
||
Directory — zmienia oczekiwany schemat i domyślny atrybut logowania), host,
|
||
port, base DN, bind DN + hasło, SSL, filtr użytkownika (`(uid={0})` dla
|
||
LLDAP, `(sAMAccountName={0})` dla AD), auto-provisioning gości, ograniczenie
|
||
tworzenia kont/zgłaszania tylko przez LDAP. Przycisk **„Testuj połączenie”**
|
||
sprawdza bind bez zapisywania zmian.
|
||
|
||
> Po świeżej instalacji (`migrate:fresh --seed`) LDAP i SMTP zawierają
|
||
> **przykładowe wartości** (`ldap.example.com`, `smtp.example.com`,
|
||
> `changeme-*-password`) — koniecznie podmień je na rzeczywiste dane przed
|
||
> oddaniem systemu do użytku.
|
||
|
||
- **Baza wiedzy BookStack** — opcjonalna integracja, **domyślnie wyłączona**.
|
||
Po włączeniu:
|
||
- **Adres instancji, Token ID, Token Secret** — token API generuje się w
|
||
BookStacku: Profil → Ustawienia API. Rola/użytkownik właściciela tokenu
|
||
musi mieć w BookStacku uprawnienie **„Access System API”**, inaczej
|
||
zapytania kończą się błędem 403 mimo poprawnych danych logowania.
|
||
- **Weryfikuj certyfikat SSL** — włączone domyślnie; wyłącz tylko jeśli
|
||
instancja BookStack korzysta z certyfikatu self-signed/prywatnego CA.
|
||
- **Przeszukuj** — trzy niezależne checkboxy: Książki / Strony / Rozdziały
|
||
(dowolna kombinacja).
|
||
- **Szukaj po** — słowa kluczowe w nazwie / tagi / oba. Wyszukiwanie po
|
||
tagach dopasowuje artykuły oznaczone w BookStacku tagiem o nazwie zgodnej
|
||
z podkategorią zgłoszenia (np. tag „Drukarki i skanery”) — patrz
|
||
automatyczne tagowanie niżej, żeby nie robić tego ręcznie dla całej wiki.
|
||
- **Dozwolone półki** — dwie **niezależne** checklisty: jedna dla podpowiedzi
|
||
przy tworzeniu zgłoszenia (klient, operator, formularz gościa na stronie
|
||
głównej), druga dla panelu bocznego operatora na widoku istniejącego
|
||
zgłoszenia. **Dopóki żadna półka nie jest zaznaczona w danej liście,
|
||
wyszukiwanie w tym kontekście nic nie zwraca** — trzeba świadomie
|
||
wskazać, które półki wolno przeszukiwać. Przycisk **„Odśwież listę
|
||
półek”** wymusza ponowne pobranie listy z BookStacka (inaczej może się
|
||
odświeżyć samoistnie po do 30 minutach po zmianie w BookStacku).
|
||
- **Pokazuj podpowiedzi także niezalogowanym** — domyślnie wyłączone; bez
|
||
zaznaczenia podpowiedzi przy tworzeniu zgłoszenia widzą tylko zalogowani
|
||
klienci/operatorzy, nie formularz gościa na stronie głównej.
|
||
- Przycisk **„Testuj połączenie”** sprawdza niezapisane wartości formularza
|
||
(analogicznie do LDAP/SMTP) i pokazuje dokładny komunikat błędu z
|
||
BookStacka, jeśli połączenie się nie powiedzie.
|
||
- **Automatyczne tagowanie treści (AI)** — przyciski **„Otaguj nową
|
||
treść”** (pomija już otagowane pozycje) i **„Otaguj wszystko ponownie”**
|
||
(klasyfikuje od nowa całą wiki) używają integracji AI (niżej) do
|
||
otagowania każdej książki/strony/rozdziału nazwami pasujących podkategorii
|
||
helpdesku — bez tego wyszukiwanie „po tagach” wyżej nic nie znajdzie.
|
||
Wymaga wcześniej skonfigurowanej i włączonej integracji AI. Dostępne też
|
||
z linii poleceń: `php artisan bookstack:tag-content` (`--dry-run`,
|
||
`--force`, `--limit=N`).
|
||
|
||
- **Snipe-IT (ewidencja sprzętu)** — opcjonalna integracja, **domyślnie
|
||
wyłączona**. Po włączeniu:
|
||
- **Adres API, Klucz API** — osobisty token API generuje się w Snipe-IT:
|
||
profil użytkownika → „Create New Token”.
|
||
- **Nie sprawdzaj SSL** — zaznacz tylko, jeśli instancja Snipe-IT korzysta
|
||
z certyfikatu self-signed/prywatnego CA.
|
||
- **Klient może wybrać sprzęt, którego dotyczy zgłoszenie** — przy
|
||
tworzeniu zgłoszenia klient widzi listę swojego sprzętu z Snipe-IT
|
||
(dopasowanego po adresie e-mail) i może je powiązać ze zgłoszeniem. Po
|
||
zaznaczeniu pojawiają się dwie dodatkowe listy wielokrotnego wyboru:
|
||
**„Ogranicz do kategorii”** — najszybszy sposób, żeby włączyć wybór
|
||
sprzętu dla wszystkich podkategorii naraz w zaznaczonych tu kategoriach
|
||
(np. zaznacz „IT-Pomoc” i „Zamówienia”, żeby objąć każdą ich
|
||
podkategorię) — oraz **„Ogranicz do podkategorii”**, do doprecyzowania
|
||
pojedynczych podkategorii niezależnie od tego, czy ich kategoria jest
|
||
zaznaczona wyżej. Wybór sprzętu pokaże się klientowi tylko tam, gdzie
|
||
trafi w którąkolwiek z dwóch list; jeśli obie są puste, opcja nie pojawi
|
||
się w żadnej podkategorii (tak samo jak dozwolone półki BookStack wyżej —
|
||
trzeba świadomie wskazać zakres).
|
||
- **Operator może zobaczyć sprzęt zgłaszającego w widoku zgłoszenia** — ta
|
||
sama lista sprzętu zgłaszającego, tym razem w panelu bocznym operatora
|
||
na widoku zgłoszenia, z przyciskiem „Powiąż” przy każdej pozycji.
|
||
- **Zezwól operatorowi na przeszukiwanie całego inwentarza** — pole
|
||
wyszukiwania z przyciskiem „Szukaj” w tym samym panelu bocznym (nie
|
||
osobna podstrona), pozwalające powiązać dowolny sprzęt z Snipe-IT, nie
|
||
tylko sprzęt zgłaszającego — przydatne dla współdzielonego sprzętu, np.
|
||
drukarek.
|
||
- Powiązany sprzęt pokazuje się na widoku zgłoszenia jako „numer środka -
|
||
numer seryjny - producent model” oraz kategoria, z bieżącym statusem
|
||
pobieranym na żywo z Snipe-IT. Przycisk „Odepnij” jest dostępny dla
|
||
operatora zawsze, niezależnie od dwóch powyższych przełączników —
|
||
odpięcie już powiązanego sprzętu to korekta, nie nowy dostęp do
|
||
Snipe-IT.
|
||
- Przycisk **„Testuj połączenie”** działa tak samo jak przy pozostałych
|
||
integracjach.
|
||
|
||
- **Integracja AI** — opcjonalna, **domyślnie wyłączona**, ogólne połączenie z
|
||
dostawcą modelu językowego (nie tylko dla BookStacka — patrz
|
||
„Automatyzacja AI dla zgłoszeń” niżej). Pola: **adres API** (dowolny
|
||
dostawca kompatybilny z OpenAI — np. Groq, OpenAI, lokalny Ollama),
|
||
**klucz API** (opcjonalny — zostaw puste dla lokalnych instancji bez
|
||
autoryzacji), **model**, **weryfikacja SSL** (wyłącz tylko dla instancji z
|
||
certyfikatem self-signed, np. lokalny Ollama). Przycisk **„Testuj
|
||
połączenie”** jak przy pozostałych integracjach.
|
||
|
||
- **Automatyzacja AI dla zgłoszeń** — wymaga włączonej integracji AI powyżej.
|
||
Zgłoszenia przetwarzane są w tle, cyklicznie (`ai:run-ticket-automation`,
|
||
interwał konfigurowalny w Konfiguracji) — nie synchronicznie przy
|
||
składaniu zgłoszenia, więc nie spowalnia to klienta.
|
||
- **Automatyczna kategoryzacja** — pięć niezależnych przełączników: przypisz
|
||
kategorię/podkategorię, gdy zgłoszenie nie ma żadnej; dobierz podkategorię,
|
||
gdy ma tylko kategorię; zweryfikuj i ewentualnie popraw już przypisaną
|
||
podkategorię; popraw temat zgłoszenia, jeśli jest niejasny; ustaw
|
||
priorytet na podstawie treści. Każde zgłoszenie jest sprawdzane **tylko
|
||
raz** — zmiany trafiają do historii zgłoszenia z adnotacją
|
||
„Automatyzacja: klasyfikacja AI” (patrz „Historia” w przewodniku
|
||
operatora).
|
||
- **Podsumowanie AI dla operatora** — osobny przełącznik generuje krótkie
|
||
podsumowanie + sugerowaną kolejną akcję dla **każdego** zgłoszenia,
|
||
widoczne tylko operatorowi (panel boczny „Podsumowanie AI” w widoku
|
||
zgłoszenia). Domyślnie odświeża się cyklicznie, wraz z pozostałą
|
||
automatyzacją AI powyżej (interwał w Konfiguracji) — operator może też
|
||
w każdej chwili kliknąć **„Wygeneruj teraz”** przy podsumowaniu, żeby
|
||
odświeżyć je natychmiast. Osobny przełącznik **„Regeneruj podsumowanie
|
||
od razu po każdej nowej wiadomości”** (domyślnie wyłączony) sprawia, że
|
||
podsumowanie odświeża się samo zaraz po każdej odpowiedzi/notatce, bez
|
||
czekania na najbliższy cykl automatyzacji.
|
||
- **Prompt systemowy podsumowania** — edytowalne pole tekstowe z gotową
|
||
wartością domyślną i przyciskiem **„Resetuj”**.
|
||
|
||
## Logi
|
||
|
||
Zakładka **„Logi”** pokazuje zawartość plików `storage/logs/*.log` (aplikacja,
|
||
IMAP, automatyzacja AI, import z Heska, itd.) bez potrzeby dostępu do
|
||
kontenera przez SSH/shell. Lista plików po lewej pokazuje rozmiar i datę
|
||
ostatniej modyfikacji (najnowsze na górze) — kliknięcie ładuje zawartość.
|
||
Filtry: poziom (ERROR/WARNING/INFO/...), wyszukiwanie tekstowe i liczba
|
||
pokazywanych wpisów (100–3000, pokazuje ostatnie N pasujących), plus
|
||
opcjonalne automatyczne odświeżanie co 5 s. Widok jest tylko do odczytu i
|
||
dostępny wyłącznie dla administratorów.
|
||
|
||
## API
|
||
|
||
Panel `/admin/api-docs` udostępnia interaktywną dokumentację (Swagger) REST API
|
||
(`/api/v1/...`) — tokeny wydaje się przez **API Clients**, z uprawnieniami
|
||
(abilities) ograniczonymi do: `tickets:read`, `tickets:write`,
|
||
`dictionaries:read` (kategorie/statusy/priorytety/zespoły), `users:read`.
|