Вишеструке пријаве и групни инциденти

Штиклирајте редове у листи тикета и кликните на „Multiple report“. Дугме постаје употребљиво од два штиклирана реда надаље.

Прозор прво пита: „Which ticket stays?“ Најстарији тикет је унапред изабран, па рок тече од првог контакта подносиоца захтева, а не од његовог другог покушаја. Можете изабрати други.

Испод стоји смер са оба броја: „#11 will be closed and moved into #10.“ Тако је пре клика јасно који тикет остаје.

Све иде са њим: коментари, прилози и опис друге пријаве. Опис постаје коментар на изворном тикету, са својим изворним аутором и својим датумом. Прозор бројеве наводи унапред.

Забележено време се премешта, а не копира. Иначе би исти утрошак стајао на два тикета и био наплаћен двапут.

Друга пријава се не брише. Она се затвара и од тада показује на изворни тикет, а њен број остаје важећи.

Подносилац захтева не добија засебну поруку. Он је на изворном тикету и тамо све види. Затворена пријава носи коментар који наводи изворни тикет, а њега може да прочита.

Опозива нема. Зато све стоји у прозору пре него што кликнете на „Merge“.

После тога историја оба тикета бележи ко је шта спојио и када.

Подносилац захтева има стари број тикета у свом сандучету. Он ништа не зна о томе да су две пријаве спојене и одговара на поруку коју има.

Тај одговор стиже у изворни тикет. Систем прати упућивање које носи затворена пријава.

Зато се спојена пријава никада не брише. Без ње упућивања не би било и одговор не би стигао нигде.

Ко је учествовао у старој пријави, сме да пише и на изворном тикету. Провера се врши на тикету наведеном у поруци.

Ако изаберете тикете различитих људи, прозор их не води са собом. Он пре клика наводи сваки одбијен ред и његов разлог.

Разлог гласи: „Different requester — this is an incident, not a multiple report.“ Он вам уз то каже куда да идете уместо тога.

Ово је најважнија брана целе функције. Када бисте спојили тридесет пријава тридесет људи, двадесет деветоро њих изгубило би свој тикет и никада ништа не би чуло назад.

Ко је подносилац захтева, најпре одлучује адреса е-поште на тикету. Ако је нема, одлучује страно име у пољу „User“, а исто име се рачуна као иста особа. Иначе се рачуна налог који је тикет направио.

Зато брана важи и за телефонске позиве. Ако оператор забележи два позива, оба тикета је направио он. Различити позиваоци ипак остају различити позиваоци, јер су њихова имена у пољу.

Ако се подносилац захтева не може утврдити на једној страни, и то се одбија. Непознато није исто што и иста особа.

У истом оквиру појављују се и други разлози. Групни инцидент не може да се споји. Затворен изворни тикет више ништа не прима. А пријава која и сама већ има пријаве не полази, па се ланци не образују.

Када падне сервер за датотеке, двадесет људи то пријави. Свака од тих пријава сопствени је предмет са сопственим подносиоцем захтева. Спајање би овде било погрешно, јер би деветнаесторо људи изгубило свој тикет.

Штиклирајте пријаве и кликните на „Group into incident“. Прозор нуди три пута: додати их групном инциденту који је већ отворен, прогласити један од изабраних тикета групним инцидентом, или направити нов групни инцидент са сопственим насловом.

Ако тим већ има отворен групни инцидент, тај пут је унапред изабран. Он је чешћи: прекид рада се одавно зна, само стално стижу нове пријаве.

Сваки повезани тикет задржава свог подносиоца захтева, свој статус и сопствени рок. Ништа не нестаје. Групни инцидент само обједињује одговор.

Све пријаве једног групног инцидента морају да припадају истом тиму. Ако прекид рада погађа два тима, сваки добија сопствени групни инцидент. Иначе би решење једног тима испразнило ред другог тима.

Закаснеле можете прикачити и на појединачном тикету. Ако тим има отворен групни инцидент, при врху се појављује напомена са „Assign“ и „Not related“. Систем никада ништа не качи сам: погрешно прикачен тикет добио би решење које га се не тиче и уз то био затворен.

Тикет групног инцидента наводи колико му је пријава прикачено. Повезани тикети заузврат носе број свог групног инцидента, и у списку и у картици с десне стране.

„Resolve incident“ затвара групни инцидент и одједном одговара на све пријаве. Текст решења је обавезан: у њему је цео смисао ове функције, јер он иде свима погођенима.

Сваки повезани тикет добија текст као јаван коментар, поставља се на изабрани статус, а његов подносилац захтева добија сопствену поруку е-поште. Без групне поруке, јер би она открила адресе свих погођених.

Порука после тога наводи колико је тикета затворено и колико је подносилаца захтева обавештено. Оба броја стоје одвојено, јер тикет без доступне адресе добија коментар и статус, али не и поруку.

Тикет на који сте у међувремену сами одговорили и затворили га остаје нетакнут. Не затвара се по други пут и не пише му се поново.

Док на групном инциденту висе отворене пријаве, он не може да се затвори обичном променом статуса. Иначе би двадесеторо људи тихо остало без одговора.

И прозор и тикет групног инцидента носе квадратић „Also show as a banner on the sign-in page“. Њиме сви сазнају за прекид рада пре него што напишу још један тикет.

Банер стоји на страници за пријаву и унутар система после пријаве. Он наводи „Known incident“ и наслов групног инцидента, па је тај наслов текст за клијенте.

Ако је укључено више обавештења, стоје једно испод другог. Одржавање најављено за суботу не потискује данашњи прекид рада, ни обрнуто.

Ако неко свеједно направи нов тикет, аутоматски одговор наводи групни инцидент. То важи и за тикет који је већ повезан и за сваки нов тикет тог тима, док год је групни инцидент отворен и најављен. За ово треба одлазна е-пошта.

Чим групни инцидент буде решен, банер сам нестаје. Нико не мора да памти да га поново искључи.

На страници „Maintenance and incident notices“ можете видети који групни инцидент тренутно стоји као банер. Прекидач на тој страници припада планираном одржавању и не важи за групне инциденте.