Användarens guide till

Support-BugzillaVersion 1.0

Digpro Solutions AB

Ulriksborgsgatan 5

112 18 , Stockholm

1 

 

Innehåll 

Inledning 2 

Skapa ett konto 2 

Användargränssnitt 3 

Skapa ett ärende 3 

Bugg- och problemrapportering 7 Exempel buggrapport 8 

Beställningsförfrågan 9 Exempel beställningsförfrågan 10 Hantering av ärenden 10 

Övrigt 13 Visa java-konsolen i Windows 10 13 Bifoga stacktrace från java-konsolen 13 

   

2 

 

Inledning Bugzilla fungerar som navet i Digpros ärendehantering. Om man som kund stöter på ett                           problem eller behov som gör att man vill komma i kontakt med Digpro är det genom                               Bugzilla kommunikationen i regel kommer att ske. Genom Bugzilla hanteras framför allt: 

● Frågor kring hur Digpros applikationer fungerar 

● Rapportering av eventuella fel och buggar 

● Önskemål och beställningar kring utökad funktionalitet 

I korthet är Bugzilla en kanal för att diskutera och hantera frågor kring Digpros                           applikationer med Digpros personal, egna kollegor och andra kunder till Digpro. 

Skapa ett konto Första steget för att få tillgång till Support-Bugzilla är att en kollega med tillgång till                             systemet lägger upp ett ärende med en begäran om ett nytt konto. I begäran ska namn                               och e-mailadress till den nya användaren inkluderas. Har man inte redan en kollega                         som har ett konto i Support-Bugzilla kan man istället vända sig till sin kontaktperson på                             Digpro, i regel den så kallade kundansvarige. 

Nästa steg, efter att begäran kommit in, är att personal hos Digpro skapar ett konto till                               den nye användaren som sedan får ett bekräftelsemail.  

 

Genom att klicka på den övre länken under To complete the change, visit the following                             link: kommer man till sidan där lösenordet kan återställas. 

3 

 

Användargränssnitt När man loggar in på support-bugzilla.digpro.se möts man av en sida från vilken man                           kan posta nya ärenden, söka bland befintliga ärenden och ändra inställningar för t.ex.                         mailutskick. 

 

Skapa ett ärende 1. För att skapa ett ärende börjar man med att klicka på File an issue på sidan man                                 

möts av efter att ha loggat in. 

4 

 

 

2. Man får sedan välja under vilken kategori (kallad product) man vill att ärendet ska                           skapas. I regel väljer man här företaget man representerar men om man sitter                         med i en av applikationernas så kallade användarföreningar och vill framföra ett                       förslag till den kan man också välja att kategorisera sitt ärende under                       Användarföreningen. 

5 

 

 

 

3. Efter att ha valt en övergripande kategori länkas man till sidan för att skriva in                             den matnyttiga informationen kopplad till ärendet. Första steget här är att visa                       de mer ingående fälten genom att klicka på Show advanced fields (vilket förstås                         redan gjorts i bilden). 

4. Under Component anger man vilken av Digpros applikationer/moduler som                 ärendet gäller. 

6 

 

5. Under Version anges applikationens version. Versionsnumret för Digpros               applikationer kan man bland annat hitta i den aktuella applikationens                   fönster-namn samt under huvudmenyn, Hjälp -> Om i applikationen. 

6. Under Severity väljer man vilken typ av ärende det handlar om. Nedan definieras                         de olika valen. Support:  Generella supportfrågor Error report:  Bugg- och felrapporter Order:  Frågor gällande beställningar och vidareutveckling 

7. Under Hardware väljer man vilken plattform (PC/Mac etc.) som används. 

8. Under OS väljer man vilket operativsystem (Windows/MacOS etc.) som används. 

Fältet Priority används till att sätta hur allvarligt man anser att felet är. Nedan                           definieras hur de olika valmöjligheterna ska användas.   Övriga fel och ärenden: Beställningar samt mindre allvarliga buggar Fel som medför störning: Buggar/problem med påverkan på verksamheten Mindre akut: Buggar/problem med stor påverkan på 

verksamheten Akut: Driftstopp (t.ex. att applikationen inte startar) 

9. Fältet Assignee ska inte editeras utan administreras antingen automatiskt eller                   internt av Digpro. 

10. Under fältet CC kan man om man vill lägga till mailadresser på de kollegor man                             tycker bör följa med i utvecklingen av det aktuella ärendet. Kravet för att man ska                             kunna lägga till en kollega är att hen har ett aktivt konto i Support-Bugzilla. 

11. Fältet Alias används i nuläget inte och behöver alltså inte fyllas i. 

12. Under fältet URL kan man lägga till eventuella URL:er som är relaterade till                         ärendet. Det kan t.ex. handla om en länk till en avbrottskarta. 

13. I fältet Summary skriver man en kortare, informativ text som beskriver ärendet.                       Texten ska vara relativt kort men ändå så pass informativ att det tydligt framgår                           vad ärendet handlar om.  

14. Hur fältet Description ska fyllas i beskrivs under rubrikerna Buggrapportering                   samt Beställningsförfrågan senare i användarguiden. 

15. Under Attachment kan man lägga till filer som är relaterade till ärendet. Det kan                           t.ex. handla om printscreens från applikationens gränssnitt. Bifogas bilder bör                   formatet PNG används medans övriga dokument i regel ska bifogas som PDF. 

16. Fältet Keywords sätts internt av Digpro. 

7 

 

17. I fältet Depends on kan man om man vill lägga till relaterade ärenden som måste                             lösas innan man kan gå vidare med det aktuella ärendet. 

18. I fältet Blocks kan man om man vill lägga till relaterade ärenden som blockeras                           av det aktuella ärendet (alltså motsatsen till Depends on). 

Bugg- och problemrapportering Om man har (eller misstänker att man har) hittat en bugg i en av Digpros applikationer                               ska detta rapporteras genom Support-Bugzilla. Det gäller även om man har ett problem                         relaterat till någon annan tjänst (t.ex. en integration) som Digpro levererat. Första steget                         i kedjan efter att en bugg rapporterats är i regel att Digpros personal försöker                           reproducera buggen i fråga i en lokal miljö. Det gör att det är viktigt att man med så stor                                     tydlighet som möjligt återger vad som inte fungerar. I många fall kan det vara så att en                                 given funktion fungerar vid ett visst tillvägagångssätt men inte vid ett annat och för att                             man ska hitta felkällan krävs det därför en fullständig specifikation av hur man burit sig                             åt då felet inträffat.  

När man skriver buggrapport ska man utgå från formen Gör, Händer, Förväntat.  

● Under Gör definierar man precis hur man ska göra för att återskapa buggen.                         Stegen ska vara numrerade och bör inledas med att man loggar in i                         applikationen (alltså: 1. Loggade in i dpPower - Demo energi AB 8.2) 

● Under Händer återger man vad som händer när man slutför det avslutande                       steget under Gör. Det kan t.ex. handla om att man får upp en feldialog eller att                               applikationen inte reagerar. 

● Under Förväntat beskriver man vad man förväntade sig skulle hända efter man                       slutförde det avslutande steget under Gör. Det kan t.ex. handla om att man vill                           att en viss symbol ska visas i en kartprodukt eller att en rapport i frågeverktyget                             ska leverera ett visst resultat. 

Utöver de tre rubrikerna Gör, Händer, Förväntat, kan man vid behov också lägga till två                             extra rubriker, Övrigt och Stacktrace. 

● Under rubriken Övrigt kan man lägga till ytterligare information som anser att                       det är viktigt att Digpros personal har kännedom om. Om man har egna                         misstankar om vad felet kan bero på (t.ex. korrupta objekt, ny version av                         applikationen etc.), vet att felet även kan återskapas vid andra tillvägagångssätt                     än under rubriken Gör eller har extra stora behov av att snabbt få hjälp kan detta                               delges Digpro under rubriken. 

● Under Stacktrace postar man den eventuella stacktrace man får i java-konsolen                     (se beskrivning senare i användarguiden) efter att man slutfört det sista steget                       under rubriken Gör. 

8 

 

Vid problem som inte handlar om buggar är det inte alltid passande att återge                           information i en numrerad steg-för-steg lista. I dessa fall är det svårt att ge tydliga                             riktlinjer för hur informationen bör formateras för att vara så tydlig som möjligt. Men                           man bör i största möjliga mån, även i dessa fall, använda formen Gör, Händer,                           Förväntat, för att återge hur felet upptäcktes. Det är även extra viktigt att man delger                             kringliggande information av värde (som t.ex. sökvägar till filer, vad funktionen ska göra)                         under rubriken Övrigt för att Digpros personal tydligt ska förstå vad som inte fungerar. 

Exempel buggrapport Nedan följer ett exempel på hur en väldefinierad buggrapport kan se ut. I det här fallet                               kan användaren inte placera en textkomponent till en brytare i schemat. 

Gör: 

1.  Startar dpPower - Demo energi AB 8.2 

2.  Loggar in i valfritt förändringsset 

3.  Startar frågeverktyget genom ikonen i övre vänstra hörnet av huvudmenyn 

4.  Öppnar flik Frågor och väljer Elobjekt -> Brytare -> Brytare 10 kV, klickar på Sök 

5.  Högerklickar på en brytare i listan, väljer Visa -> Visa i annan vy -> Gör om till schema 

6.  Högerklickar på brytaren, väljer Placera komponent till objekt  

7.  Väljer Text ID schema i listan 

8.  Högerklickar och väljer Placera utan rotation  

Händer: 

Text ID:t till brytaren placeras inte i schemat efter att man utfört steg 8 och man får även en                                     stacktrace. 

Förväntat: 

Att ID:t går att placera i schemat. 

   

9 

 

Övrigt: 

- Problemet gäller oavsett spänningsnivå på brytaren. - Felet uppkom efter att vi uppgraderat till version 8.0. 

Stacktrace: 

2017-11-28 16:33:47 [1cda43fe:c7cbcf5b:3f45ea56:116ae55f] bios.jcommon.exception.BiosException: Unknown exception (bifoga alltid allt, hela stacktracen, från java-konsolen). 

Beställningsförfrågan Om man är intresserad av eller har idéer kring utökad funktionalitet i en applikation är                             det viktigt att Digpro får en så djup förståelse som möjligt kring själva behovet. Digpros                             applikationer har ett stort bibliotek av funktioner vilket gör att det ibland kan vara så att                               den funktion som efterfrågas redan finns inkluderad. Även i annat fall fyller det också                           en stor funktion att Digpros personal har djup kännedom kring grundbehovet eftersom                       det gör det betydligt enklare att gemensamt diskutera sig fram till en lösning som är                             både framtidssäkrad och robust rent tekniskt. 

En beställningsförfrågan bör vara uppbyggd kring tre huvudpunkter: Gör, Händer och                     Förfrågan. 

● Under rubriken Gör definierar man tydligt vad man gör i anslutning till det att                           problemet/önskemålet uppkommer. Det kan t.ex. handla om att man letar efter                     en viss typ av information i ett formulär eller att man panorerar i en kartprodukt.                             Informationen kan, men behöver inte nödvändigtvis vara återgiven i en                   numrerad lista. 

● Under rubriken Händer beskriver man problemet man har i anslutning till det                       som återges under rubriken Gör. Det kan t.ex. handla om att man anser att                           informationen i ett formulär är onödigt svår att tillgå eller att en kartprodukt                         uppfattas som plottrig. 

● Under Förfrågan beskriver man själv hur man skulle vilja att applikationen såg ut                         eller betedde sig i anslutning till rubriken Gör. 

Det kan även här, precis som vid buggrapportering, vara bra att lägga till en rubrik Övrigt                               där man delger övrig information som man tror eller anser är viktig för Digpro.   

10 

 

Exempel beställningsförfrågan Nedan följer ett exempel på hur en väldefinierad beställningsförfrågan kan se ut. I det                           här fallet är man intresserade av att se olika uppdragssymboler beroende på vilken                         applikation ett uppdrag är skapat i. 

Gör: 

1. Startar dpPower - Demo energi AB 8.2 2. Visar sidomeny, öppnar flik karta, öppnar kartprodukt Samlingskarta 3. Öppnar huvudmeny, Fönster -> Flytta vy till koordinater 4. Fyller i 

X (N): 659 3000 Y (E):  672 000 Skala: 5 000 

Händer: 

Landar i en punkt i kartan (Täby) där många olika uppdragssymboler är utplacerade.                         Problemet är bara att alla har samma symbol och att det är svårt att skilja uppdragen åt. 

Förfrågan: 

Vi vill framför allt skilja på uppdrag beroende på vilken applikation de är skapade i, alltså                               beroende på om de skapats i dpCom eller dpPower. En idé skulle t.ex. kunna vara att                               dpCom-uppdrag symboliseras av en fiber och dpPower av en blixt. 

Vi är i första läget intresserade av en tidsuppskattning så bestämmer vi efter det hur vi ska gå                                   vidare. 

Hantering av ärenden Första steget när ett ärende tas emot är att Digpros personal läser igenom                         informationen i sin helhet och sedan ger en första återkoppling till den som skapat                           ärendet. Det kan handla om att information saknas och att följdfrågor därmed behöver                         ställas eller helt enkelt att ärendet mottagits och väntar på att resurssättas. Beroende                         på hur ärendet klassificerats under fälten Severity och Priority samt vad som står under                           Description avgör Digpro hur ärendet ska prioriteras. Ärenden som anses akuta och har                         stor påverkan på verksamheten prioriteras av naturliga skäl högre än ärenden med                       lägre grad av påverkan. 

Om ett ärende inte är så pass akut att det måste hanteras direkt kommer Digpros                             personal först och främst se till att det är tydligt definierat precis vad som ska göras och                                 efter det lägga till ärendet i en intern kö. Att ärendet ställts i kö kan man se på fältet                                     Keyword. Ärenden som uppskattas ta mindre än 4 timmar att slutföra taggas av Digpro                           med keywordet grab-me. Ärenden som uppskattas ta mer än 4 timmar taggas med                         

11 

 

keywordet listed-gis samtidigt som ett ärende skapas i Digpros interna                   ärendehanteringssystem. 

I ett ärende har man i stort sett samma möjligheter att i efterhand lägga till information                               som man har när man först skapar ärendet. Ser man t.ex. att man råkat fylla i fel                                 information i ett visst fält är det med andra ord inget problem att rätta till det i                                 efterhand. 

 

Utöver de fält som specificerats under kapitlet Skapa ett ärende är det egentligen bara                           ytterligare två man som Support-bugzilla-användare behöver ha kännedom kring: 

12 

 

1. Till höger om fältet Modified finns en länk, History. Under den kan man själv se                             när och hur ärendet i fråga har hanterats.  

2. Under fältet Status definieras vilken status ett ärende har för närvarande. Fältet                       har följande valbara alternativ: UNCONFIRMED NEW IN_PROGRESS FOR_CUSTOMER_FEEDBACK RESOLVED VERIFIED CLOSED 

UNCONFIRMED - Är den initiala statusen för ett ärende innan det har tagits emot av                             Digpros supportavdelning. 

NEW - Ett ärende har statusen NEW under tiden det genomgår en initial hantering och                             är kölagt. 

IN_PROGRESS - När ett ärende aktivt hanteras av Digpro har det statusen                       IN_PROGRESS. 

FOR_CUSTOMER_FEEDBACK - När Digpro har ställt en fråga till personen som skapat                       ärendet, sätts statusen till FOR_CUSTOMER_FEEDBACK. När man svarat på eventuella                   frågor kan man sätta tillbaka ärendet till samma status det hade innan det som stod                             som FOR_CUSTOMER_FEEDBACK. I regel antingen NEW eller IN_PROGRESS. 

RESOLVED - Under tiden mellan det att Digpro anser att de har löst ett ärende men                               man som kund inte haft möjlighet att verifiera det i sitt eget system (t.ex. p.g.a. att man                                 först måste uppgradera till en ny version av applikationen) ska ärendet ha statusen                         RESOLVED. 

VERIFIED - När man som kund verifierat att en lösning fungerar i sitt system sätts                             statusen till VERIFIED. 

CLOSED - Sista anhalt efter att en lösning verifierats är att ärendet stängs av Digpros                             personal genom att statusen sätts till CLOSED. Man kan endast sätta statusen CLOSED                         om ärendet tidigare är antingen i status RESOLVED eller VERIFIED. 

   

13 

 

Övrigt Nedan följer en kortare beskrivning av övriga delar som kan vara bra att känna till när                               man skapar ett ärende i Support-Bugzilla. 

Visa java-konsolen i Windows 10 För att kunna läsa och bifoga så kallade stacktraces (felrapporter som ibland kan                         genereras av buggar i applikationerna) behöver man först slå på den så kallade                         java-konsolen. För att automatiskt få upp java-konsolen när man startar applikationen i                       Windows 10 kan man:  

1. Öppna Start-menyn och skriv Kontrollpanelen  2. I sök-rutan, högst upp till höger i det nya fönstret, skriv Java och klicka på                             

ikonen med kaffekoppen som visas 3. I det nya fönstret, Java Kontrollpanel, öppna fliken Avancerat 4. Under rubriken java-konsol, välj Visa konsol  5. Klicka på OK 

Bifoga stacktrace från java-konsolen Stacktracen som i vissa fall genereras av buggar i applikationen innehåller värdefull                       information som kan användas för att Digpro snabbare ska kunna hitta och                       implementera lösningar på de problem som rapporterats. När man bifogar en                     stacktrace är det viktigt att man bifogar allt som visades i java-konsolen efter att man                             utfört det sista steget under Gör: i buggrapporten. Stacktracen börjar med en                       tidsstämpel och på så sätt är det lätt att förstå varifrån felet härstammar.   

14 

 

Exempel på stacktrace kan ses nedan: 

2018-01-23 09:13:04 [ee4546be:b8584049:7160ea79:da85b79b] java.lang.NullPointerException 

at sys.insp.jcommon.plans.PlanContent.getLastInspection(PlanContent.java:46) at sys.insp.plugin.qt.view.InspPlanTemplatePanel.<init>(InspPlanTemplatePanel.java:70) at sys.insp.plugin.qt.view.InspPlanTemplateView.<init>(InspPlanTemplateView.java:29) at 

sys.insp.plugin.qt.factory.InspPlanTemplateViewFactory.getInspPlanTemplateView(InspPlanTemplateViewFactory.java:96) at sys.insp.plugin.qt.factory.InspPlanTemplateViewFactory.build(InspPlanTemplateViewFactory.java:24) at bios.plugin.qt.factory.QtViewManager.createQtView(QtViewManager.java:580) at sys.insp.plugin.qt.factory.InspPlanTreeTableFactory$2.doCall(InspPlanTreeTableFactory.java:280) at bios.plugin.ClientAsynchVoidCall.call(ClientAsynchVoidCall.java:37) at bios.plugin.ClientAsynchVoidCall.call(ClientAsynchVoidCall.java:11) at bios.jcommon.AsynchCallService.lambda$submit$1(AsynchCallService.java:129) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)