Brukerveiledning for RT saksbehandlere

 
 

1) Innledning

Request Tracker (RT) er et system for ? behandle henvendelser. Systemet gj?r det mulig for en gruppe mennesker ? h?ndtere henvendelser, foresp?rsler, feilmeldinger og lignende som kommer inn via et e-postsystem. Henvendelser og foresp?rsler som kommer per telefon, m? saksbehandler selv registrere i RT. 

RT er et system som er utviklet for ? h?ndtere n?kkeloppgaver som identifisering, prioritering, tildeling, l?sning av saker.

 

2) ? v?re saksbehandler i RT

2.1) Oppretting av bruker

Dersom du er k?sjef og ?nsker ? vite hvordan man melder inn en ny saksbehandler i din k?, se veiledning her.

Du m? v?re definert som en bruker av systemet. Dette inneb?rer at du sender en henvendelse per e-post for ? bli automatisk opprettet. Dette b?r du ikke gj?re samme dagen som du ble opprettet som UiO-bruker, siden brukeren skal inn i en lang rekke automatiske systemer f?rst. Vent ca. et d?gn.

Send mail til general@rt.uio.no og be om ? bli bruker. Like etter at du har sendt mailen, f?r du en mail tilbake med beskjed om at saken din er registrert. P? dette tidspunktet har du f?tt en bruker i RT og kan logge inn med ditt vanlige UiO-brukernavn og -passord. Rettigheter i RT styres med nettgrupper. K?sjefer har mulighet til ? melede personer inn/ut av disse gruppene. Fra en bruker er meldt inn i en nettgruppe kan det ta 30 minutter f?r denne f?r riktige rettigheter i RT.

2.2) Kunde kontra saksbehandler

En kunde som sender et sp?rsm?l til en e-postadresse som er tilknyttet som k? i RT, f?r en tilbakemelding umiddelbart om at saken er kommet inn i k?en. I denne meldingen f?r vedkommende tilbud om ? f?lge med p? sin egen sak.

Standard melding fra RT

Som nevnt er intensjonen at kundene (requestor) ikke skal beh?ve ? ha noen bevissthet om RT. Kunden forholder seg bare til de tilh?rende e-postadresser. N?r saken avsluttes f?r kunden automatisk en kort standardmelding om dette, uten noen merknader fra saksbehandler.

Utover dette er det ikke automatikk for at RT sender annen informasjon til kunden. Likevel kan saksbehandleren i RT velge ? sende kunden informasjon ved viktige milep?ler underveis i saksbehandlingen, der dette kan tenkes ? v?re relevant for kunden.

Alle kunder som sender henvendelser til RT opprettes automatisk som uprivilegerte brukere i RT. Enhver slik bruker kan logge seg p? RT med vanlig UiO-brukernavn og passord (for eksterne er brukernavn e-postadressen og passordet tilsendt). Kunden kommer da til en egen del av RT som heter RT Self Service. P? denne nettsiden f?r kunden innformasjon om det meste i alle sine saker, samt mulighet til ? registrere nye saker i RT. For ? kunne finne fram til sin egen sak m? kunden vite saksnummeret.

Informasjonen er omtrent den samme som saksbehandleren f?r n?r han/hun velger ? se p? en enkelt sak i Display-modus.

 

?pne saker i RT

 

Klikk p? saken for ? se saksgangen..

3) Navigasjon

3.1) Viktige momenter omkring navigasjon

RT benytter b?de sekund?r og terti?r navigering for ? gj?re det mulig ? hoppe til nesten alle andre funksjoner som en saksbehandler trenger. Du vil derfor se at mengden linker som er tilgjengelig  forandres hele tiden, avhengig av din posisjon i RT. Minste menyen du kan finne er til venstre p? bildet under: hovedmenyen.

 

 Hovedmenyen i RT

 

Under redigering av RT at a glance (kapitel 6) vil du oppleve at toppmenyen kan f? en rekke sekund?re og terti?re menyer, avhengig av hvor i RT du er plassert:

 

I eldre versjoner av RT, kunne man klikke seg frem til de neste niv?ene av menyen - i den nyeste holder det ? holde musepekeren over bestemt kategori. Legg merke til at RT indikerer neste niv? i menyen med en pil.

Ikke fall for fristelsen til ? velge back p? nettleseren n?r du arbeider i RT. Applikasjonen er lagt opp slik at du alltid skal kunne finne fornuftige valg p? menyene uten ? skulle beh?ve og g? tilbake vha nettleserens egen meny. Er du i tvil kan du alltid hoppe "helt hjem" vha menyvalget Homepage helt ute til venstre p? hovedmenyen!

 

4) Vanlige oppgaver for en saksbehandler i RT

De vanligste oppgavene for saksbehandleren er:

  • Logge inn
  • Tilpasse egen velkomstside (RT at a glance)
  • S?ke etter saker
  • Opprette nye sak
  • Besvare og kommentere saker
  • Modifisere en sak (f.eks. prioritet og tidsfrister)
  • L?se en sak
  • Endre egen brukerinformasjon (ut over det RT henter fra LDAP)
  • Logge ut

 

4.1) Innlogging

B?de interne og eksterne brukere opprettes automatisk ved f?rste henvendelse til RT. Interne brukere f?r vanlig UiO brukernavn og passord. Eksterne brukere f?r e-postadressen som brukernavn og f?r vanligvis tilsendt et generert passord. Eksterne brukere f?r ikke tilsendt passord dersom de blir opprettet ved bruk av CC p? en sak.

 

Innlogging

 

4.2) S?kefunksjonen

4.2.1) Direkte s?k

S?king i RT kan foreg? fra mange posisjoner. Det f?rste du m?ter p? er s?kefeltet oppe til h?yre n?r du nettopp har logget deg p? eller klikket p? Homepage.

 

Hovedsiden

 

Dette er et friteksts?k som gir deg muligheten til ? finne saker hvor du bare vet f.eks. et ord som er nevnt under Subject eller du skriver sakens k?nummer. Jo mer generelle ord du s?ker p? jo flere treff blir det og jo vanskeligere er det ? finne akkurat den saken du leter etter. Det er derfor en stor fordel jo flere ord du skriver inn i s?ket. Treffene p? s?ket kommer opp i en liste der du ogs? f?r se status, k?ens navn, eier av saken og sakens prioritet i RT (jo lenger det er siden den ble opprettet jo h?yere prioritet har den i systemet). Her er et s?k p? tickets som inneholder ordet Houston:

 

S?k p? ordet Houston i RT

 

4.2.2) Simple search

Du kan ogs? benytte deg av simple search som er plassert under Search >> Tickets >> Simple Search.

 

Enkelt s?k i RT

 

I dette s?keoppsettet foresl?r RT en rekke s?kekriterier som du kan s?ke p?: 

"Search for tickets. Enter id numbers, queues by name, Owners by username and Requestors by email address. RT will look for anything else you enter in ticket bodies and attachments.
Searching the full text of every ticket can take a long time, but if you need to do it, you can search for any word in full ticket history for any word by typing fulltext:word.
RT will look for anything else you enter in ticket subjects."

 

S?ket som foreg?r fra denne s?keruten er avhengig av syntaksen p? s?kekriteriene. Eksempel p? dette er at hvis det forekommer en @ i s?kestrengen antar RT at du s?ker etter en e-postlist/k?. Hvis du har et ord med sm? bokstaver p? ca. 5-8 tegn antas det at det er et brukernavn det s?kes etter osv osv.

 

4.2.3) S?ketreff og lagring av s?k til rutinemessig bruk

N?r du har f?tt opp dine treff p? s?k har du en egen meny for valg du vil gj?re med s?ketreffene.

 

S?ketreff

 

EDIT SEARCH sender deg til en side hvor du kan finjustere s?kekriteriene. Tittelen p? siden heter Query builder og kriteriene som du setter opp kan lagre til seinere. Siden antall saker og innholdet i dem ?ker kontinuerlig vil ett og samme s?k sannsynligvis gi flere antall treff i morgen kontra idag. Det kan derfor v?re smart ? lagre et s?k som du vet du kommer til ? trenge ofte. Da vil du raskt kunne finne de korrekte sakene uten ? m?tte tenke igjennom og bygge s?ket for hver gang du skal bruke det. Du kan til og med lagre s?kene i egne bokser som du kan legge p? din egen RT-forside (RT at a glance), slik at s?ketreffene kommer opp hver gang du logger deg p? RT.

Query builder best?r hovedsaklig av to deler: Selve s?ket og organisering av resultater. ?verste delen hjelper deg med selve s?ket, og du vil se Current search feltet endre seg ettersom du oppdaterer kriteriene for s?ket. I nederste del av Query builder kan du angi hvordan du ?nsker resultatlisten etter s?ket skal se ut, og spesifisere andre sorteringer enn det som er standard i din RT. Dette gj?r du ved ? angi hvilke kolonner som skal v?re med, hvilken rekkef?lge og hvordan listen skal sorteres. Til slutt l?nner det seg ? lagre s?ket for senere bruk. Du kan lese mer om hvordan man oppretter enkle s?k her.


Opprette s?k

 

Hvis du vil finne frem til dine saker avhenger det av hvilken rolle du har i RT. Denne veiledningen henvender seg til saksbehandlere. Hvis du st?r som saksbehandler (owner) av én spesifikk sak kan du s?ke etter den ved f.eks. ? angi ditt brukernavn i owner-feltet. Du f?r da opp alle saker hvor du er owner og kan (forh?pentligivs) bla raskt igjennom disse og kjenne igjen saken som du leter etter.

 

4.3) G? direkte til en sak du kan ticketnummeret til

Et viktig triks ? v?re klar over er at hvis du kan ticketnummeret (den unike koden til en enkelt sak), s? kan du skrive den direkte i adressefeltet etter https://rt.uio.no/######. Da ?pnes saken direkte etter at du har logget deg p?. Du kan ogs? fylle inn ticketnummeret i s?kefeltet oppe til h?yre i skjermbildet.

 

4.4) Opprette en ny sak inne fra RT

De fleste saker blir opprettet ved at det kommer e-post til k?en fra en bruker. Du kan imidlertid, som saksbehandler, opprette nye saker mens du er inn i RT. Det gj?r du ved ?

  • navigere deg tilbake til din egen forside (klikk Home oppe til venstre)
  • velg hvilken k? saken skal opprettes i (?verst til h?yre)
  • klikk p? knappen new ticket in

 

Lag ny ticket

 

Vinduet som dukker opp ligner mye p? hvordan det er s? sende e-post via en nettbasert l?sning.

 

Avansert bruk av lag ny ticket

Kommentarer til utfylling av new ticket in

Fyll ut feltene s? n?yaktig som mulig. Hvis du bruker tid p? ? fylle inn korrekte og utfyllende opplysninger n?, sparer du tid senere b?de for deg selv og eventuelt andre som m? jobbe for ? f? saken l?st. Grensesnittet til Create a new ticket er avhengig av hvilken k? men oppretter saken i. Man vil kunne se noen sm? forskjeller avhengig om k?en har noen custom fields eller ikke, dersom den har det - fors?k ? kategorisere saken ut fra disse, s? n?yaktig s? mulig for ? skape best mulig oversikt.

Status

Det f?rste feltet som m? fylles ut p? en ny sak er status, standardverdien er new. Hvis du klikker p? pilen til h?yre for feltet vil du se at de alternative verdiene her er: open, stalled, resolved, rejected og deleted. Vanligvis skal du alts? benytte standardverdien her. Eksempler p? tilfeller hvor du skal bruke noe annet enn new som status

  • Open dersom den ikke lenger er ny, men fortsatt ikke er l?st.
  • Stalled (lagt p? vent eller pauset) P.g.a omstendigheter utenfor din kontroll jobbes det ikke med saken akkurat n?. Du venter kanskje p? et svar eller en oppklaring fra kunden, fra en utviklingsavdeling, en driftsavdeling eller lignende.
Owner

Etter status fyller du ut Owner – her skal det st? et brukernavn for saksbehandler. Hvem har ansvar for ? l?se denne saken? Skriv inn hans/hennes brukernavn i feltet owner. Saker skal alltid ha en person som eier. Hvis det er vaktordninger etc. som benyttes, s? skal dette styres via k?ene. Dersom  du har tenkt ? ta saken, kan du skrive ditt brukernavn.

Merk! Hvis det ligger mange navn i Owner-listen kan det v?re et tips ? skrive inn f?rste bokstav i brukernavnet, s? s?ker RT internt i listen.

Requestor

Dette feltet skal inneholde adresse til innsenderen eller kunden, alts? den som skal f? svaret. RT setter i dette feltet automatisk v?r adresse, men ikke i alle tilfeller er det vi som sp?r om noe - men at vi oppretter saker p? vegne av andre som f.eks har kontaktet oss personlig eller via en telefonsamtale. I slike tilfeller skal man fjerne sin egen adresse og skrive adressen til vedkommende vi har snakket med tidligere.

Viktige momenter omkring oppf?ring av personer i CC-feltet, og videre korrespondanse i en sak

Som du ser av skjemaet har Requestor mulighet til ? skrive et navn eller en postliste i CC-feltet (kopi til). Alle som oppf?res i CC-feltet blir automatisk Watcher i saken og f?r kopi av all videre korrespondanse. Men n?r det er saksbehandleren som f?rer opp en e-postadresse i CC-feltet vil ikke de allerede eksisterende partene i saken se at det g?r kopi til denne nye personen i saken. Dersom Requestor igjen sender inn en kommentar i den samme saken g?r det automatisk kopi til personen som saksbehandleren f?rte opp i CC-feltet. Requestor kan alts? ikke se dette. Ved eventuelle saker som er sendt inn i RT via e-post fungerer CC-feltet tilsvarende. V?r oppmerksom p? at ved saker som sendes inn via e-post blir den som st?r i Reply-to feltet Requestor (kunde) for saken.

Annet viktig omkring roller, saker og hvem som f?r se trafikken i en sak
  • Requestor og de som st?r angitt i CC-feltet f?r alle replies, men ikke comments. AdminCC f?r se alle replies og alle comments.
  • Det er saksbehandler som kan bestemme hvem som skal v?re Watcher i en sak.
  • N?r man kommuniserer i RT dukker det stadig opp et CC-felt hvor du kan putte inn mottagere som du mener trenger kopi av denne ene meldingen. Dette er foreg?r som en enkelthendelse mottagere av disse enkeltmeldingene blir ikke fast Watcher videre i saken.
  • Subject-feltet er sv?rt viktig. Fyll ut med beskrivende tekst og bruk sm? bokstaver.
  • Du ser at du ogs? kan legge til et eller flere vedlegg. Hvis du jobber med feilh?ndtering kan du for eksempel legge ved kopier av feilmeldinger som du mottar som fil som et vedlegg til saken i RT.
  • Beskrivelse av saken er ogs? viktig og nyttig, b?de for saksbehandlere selv og hvis det er flere som m? innom for ? l?se samme sak. Beskrivelsen er ogs? viktig for mulig bruk av lukkede saker som erfaringsdata i organisasjonen. Klikk p? Show details for ? sette prioritet og tidsfrist p? saken. N?r du har fylt ut alle felt s? godt du kan, klikker du p? Create (langt nede til h?yre) for ? opprette saken. Den f?r n? et unikt nummer i systemet som f?lger saken.
  • Hver gang du sender en sak st?r det nederst en liste over de som f?r kopi av meldingen. Du kan selv fjerne en eller flere mottagere av hver eneste melding som er p? vei ut.
  • Saksbehandlere kan slette mottagere av kopier i en sak for resten av saksbehandlingen
  • OBS: Saksbehandler f?r ikke automatisk kopi av nye meldinger i saken. RT antar at saksbehandler f?lger med p? sine saker s?pass n?ye at det ikke er n?dvendig med en slik melding!

 

4.5) Automatisk tilbakemelding p? henvendelser

For ? lage meldinger i RT som automatisk sendes ut , f.eks som en kvittering p? at henvendelsen er mottatt, brukes en kombinasjon av scrips og templates i RT. Denne kvitteringen er felles for alle saker i en k?. Alle som sender inn saker f?r tilbake en kvittering med lenke til saken, slik at de kan f?lge med i saken p? web. Kvitteringen sendes til den e-postadressen som st?r oppgitt i Requestor feltet. 

4.6) Saksgang

typisk saksgang i RT

 

 La oss ta n?rmere titt p? en sak. Man kan lage seg ulike oversikt over k?er man har tilgang til - det hvordan f.eks RT at a glance er bygd opp er avhengig av personlige preferanser. Du kan lese mer om dette her. I skjermbilde under kan du se at helt nederst finner man sak uten eier, der st?r det oppf?rt under Owner, Nobody in particular.

 

 

Etter ? ha trykket p? saken vi vil behandle kommer vi inn i undermenyen "Display". Denne viser sakens basale egenskaper og vi f?r en grei oversikt av de viktigste tingene i saken som f.eks hvem som eier saken og hvem som er innsenderen. Under metadata til saken, finner du historikken.

 

 

N? har vi kommet stadiet hvor vi vil "ta" saken. Enkelt nok trykker man p? "Take", som vist p? bilde under, og saken oppdateres automatisk med deg som owner.

 

 

N?r en saksbehandler med de rette rettigheter tar saken s? vil den med en gang begynne ? f? en historikk i systemet. Saksbehandleren vil kunne skrive inn detaljer som prioritering, datofrister og lignende. Etter hvert som saken behandles og l?ses vil du se at f.eks. status og prioritet forandres p? informasjonssiden.

  • New - Saken er ny og venter p? at noen skal ta den
  • Open - Saken er tatt og venter p? ? bli l?st
  • Resolved – saken skal bytte status til resolved n?r du mener den er avsluttet og lukket
  • Rejected – betyr at saken er avvist. Dette er til bruk for meldinger som ikke skal l?ses av saksbehandlere, f.eks sp?rsm?l som oppfattes som usaklige eller uten relevans
  • Deleted – saken er slettet. Denne kan for eksempel brukes hvis spam-meldinger kommer inn i systemet. Saken (ticket) vil da f? status inaktiv og vil ikke komme fram i s?k og lignende, samt at saken vil bli slettet av en slettejobb som g?r jevnlig.
  • Stalled - betyr at saken, av en eller annen grunn er stoppet/satt p? vent. RT har ingen direkte informasjon utover dette

Klikk p? IsSpam om du er sikker p? at en sak er spam. Om du er i tvil flytter du saken til k?er spam-suspects og overlater resten til Houston.

RT kan ogs? settes opp for ? sende varsel om enhver statusendring automatisk. Vi har valgt ? ikke bruke denne automatikken globalt, men det kan eventuelt tilf?yes for de k?ene der det er aktuelt.

 

4.7) Endre bemanning av saker | endre eierskap til en sak

Det finnes to forskjellige fremgangsm?ter for ? bytte eier til en sak. Man kan enten trykke p? a) Basics i saksoversikten eller b) velge Basics fra navigasjonen ?verst til h?yre.

 

N?r man trykker p? Basics vil man f? opp et nytt oversikt over de grunnleggende egenskapene til saken. Derfra under Owner, vil du kunne fjerne f.eks ditt brukernavn og deretter vil du kunne skrive et annet brukernavn. Husk ? lagre endringer under Save Changes.

Merk! Hvis det ligger mange navn i Owner-listen kan det v?re et tips ? skrive inn f?rste bokstav i brukernavnet, s? s?ker RT internt i listen.

 

4.8) Modifisere/behandle en sak

Prim?rt er RT er satt opp til ? vise dine viktigste saker listet opp i en egen boks p? f?rstesiden i sonen "body"

 

 

 

Klikk p? den saken (ticket) du ?nsker ? jobbe videre med. En saksbehandler som har nok rettigheter til ? jobbe med saken f?r opp saken og kan velge hva vedkommende vil gj?re med den.

* OPEN = Et klikk p? denne linken ?pner saken. Det vil si at den er ?pen for saksbehandling.

* TAKE = Betyr at du tar over saken og ansvaret for ? l?se den. Du vil se at eier (owner) skifter fra nobody til ditt brukernavn. V?r klar over at menyen som viser hva du kan gj?re videre i saken forandres, men du finner fortsatt igjen "Comment · Reply · Resolve · Extract Article · IsSpam" ute til h?yre.

Etter man har tatt saken og ?pnet den f?r man opp diverse funksjoner. Man deler funksjonene til en sak opp i to hoveddeler. Den ene tar for seg alle funksjoner som gjelder hele saken, mens den andre tar for seg funksjoner som gjelder bare for den enkelte meldingen i saken. F?rst skal vi se p? funksjonene for hele saken:

 

 

* COMMENT eller REPLY = Det er to m?ter ? besvare en sak p?, enten reply eller comment. Hvis du bruker reply vil alle kunne lese svaret, og det sendes e-post til requestor. Hvis du bruker comment vil ingen kunder (requestor) kunne se det. Husk ? klikke "Save changes" dersom du har endret listen av mottakere. B?de svar (reply) og kommentarer (comments) kommer fram hvis du som saksbehandler ser p? historien til en sak. N?r du er ferdig med ? jobbe med meldingen m? du klikke p? Update Ticket for at endringene skal bli lagret i databasen.

* RESOLVE = vil si at du l?ser saken og at du sammen med l?sningen sender en beskjed til requestor om at saken er lukket

* ISSPAM = hvis saksbehandleren ser at det er spam kan vedkommende sende den ut av systemet ved ? trykke p? IsSpam. Etter du har trykket IsSpam knappen vil du trolig f? opp en feilmelding som bare indikerer at du ikke har tilgang til k?en der IsSpam blir h?ndtert.

* BOOKMARK = Stjernene som kan sees b?de p? Homepage og ved lagring av de forskjellige tickets kalles for bokmerker. For eksempel kan en markere de sakene man vil jobbe med idag, og fjerne bokmerke etter man er ferdig. Det er en fin m?te for seg selv ? holde kontroll p? diverse forskjellige saker. Disse stjernene er individuelle for hver bruker, og ikke for hver sak. Det betyr at dersom du setter et bokmerke p? en sak, vil det bare synes at den er bokmerket for din bruker.

 

Hver sak har ofte flere meldinger ved bruk av comment og/eller reply. Hver av disse meldingene har igjen egne funksjoner:

 

* REPLY/COMMENT av en enkelt melding fungerer p? litt annerledes m?te enn ? bruke reply/Comment p? hele saken. Ved ? bruke reply/comment p? denne m?ten vil du 'quote' denne meldingen du jobber med. Det betyr at alt som st?r over "Jeg synes brukerdo er kjempe fin, men det er en ting som er uklart..." vil v?re det f?rste som st?r i den nye meldingen du oppretter. Denne funksjonen kan v?re veldig lur dersom det er mange og uoversiktlige meldinger i en sak, men samtidig kan den v?re mye til bry ettersom all informasjonen kommer om igjen.

*FORWARD: Forward funksjonen bruker du dersom du skal sende akkurat denne meldingen du holder p? med til en adresse. Du trykker forward og skriver deretter inn adressen du vil sende denne meldingen til.

*CLONE = Du tar meldingen i ticket'en du holder p? n? og "kloner" den til en ny ticket. Det vil bli opprettet en ny sak hvor meldingen du holdt p? med vil v?re den f?rste i den nye saken. Du velger k? hvor klonen skal v?re og oppretter som vanlig saken der.

 

NB: Editoren fungerer ikke som den skal for alle brukere. Den er deaktivert for ?yeblikket, men hver enkelt kan aktivere den p? egen h?nd!

N?r du skriver en reply/comment, brukes samme redigeringsm?te som i Vortex. For ? se editorpanelet m? du trykke p? den lille pilen vist p? bildet under

 

 

og editoren vil poppe opp slik:

 

 

4.8.1) Oppdatere flere saker samtidig og informasjon om det ? forandre p? saker

Det er ogs? mulig ? oppdatere mange saker p? en gang. For ? gj?re dette velger du alle sakene du ?nsker ? oppdatere f. eks gjennom et s?k, velg deretter menyen update multiple tickets. Du kommer n? inn i et skjermbilde der du kan legge inn svar eller kommentar p? alle sakene p? en gang. Husk ? klikke Update all n?r du er ferdig.

 

4.8.2) Andre endringer p? saker

Merk! Save Changes brukes hvis det skjer endringer i en sak som for eksempel at flere legges til i cc-feltet og skal ha kopi av saksgangen, da m? du f?rst velge Save Changes og deretter Update Ticket. Hvis du kun trykker Save Changes blir ikke saken oppdatert i databasen.

Du vil ellers kunne endre prioritet, k?, tema (subject), tidsfrist (due date) med mer. Historien for en sak kan dog ikke endres.

Hvis du vil at flere brukere skal f? e-post om denne saken kan du legge til en gruppe eller en person ved ? bruke add a watcher og deretter search for users og velge bruker eller search for groups og velge gruppe. Du m? ogs? tildele en rolle til brukeren eller gruppen som du velger som watcher. Rollene en watcher kan ha er cc eller AdminCC.

 

4.9) Samle saker

Hvis det finnes saker som er sendt til flere k?er, blir dette duplikater i databasen. For ? unng? dette b?r sakene samles, bruk Merge p? sakene. Det b?r gj?res en vurdering av hvor samlesaken b?r ligge, alts? i hvilken k?. Eksempel: S?k via fellesnevner for saken, for eksempel subject inneholder ordet 'test'. N?r du har f?tt opp alle sakene som skal samles, velg update multiple tickets, marker vekk den f?rste av sakene i listen, og samle de f?lgende inn i den f?rste og sjekk at samlesaken n? ligger i riktig k?.

 

4.10) Bytte av k? 

Det er to hovedtilfeller ved saker som skal bytte k?. Det f?rste og mest frekvente g?r p? saksgangen - en sak trenger hjelp fra flere personer og blir flyttet imellom k?er. For eksempel hvis saken er handle i en k? hvor saksbehandler bare er kompetent til ? svare p? deler av problemet. UiO har idag (jun 2009) satt opp RT slik at hvis en sak flyttes til en annen k? s? g?r det ut en melding til alle relevante parter i saken om at dette har skjedd.

Det andre tilfellet er rett og slett at saken har havnet i feil k? helt fra starten. Da er det k?-sjefens oppgave ? videresende til riktig k?.

For ? bytte k? g?r man inn p? saken og trykker menyen "Jumbo". Som vist p? bildet under trykker man p? scroll-menyen og velger den k?en saken skal legges inn i. Her har vi byttet k? fra rt-test til request tracker.

 

 

Vi skal innarbeide som fast rutine at saksbehandler sender kunden en forklarende melding fra RT ved enhver viktig endring i saken, som for eksempel n?r saken flyttes til en ny k? og dette kan anses som en vesentlig endring for kunden. I selvbetjeningsbildet til RT kan kunden alltid se hvilken k? saken tilh?rer.

 

4.11) L?se en sak

S?rg for at saken (ticket) f?r status resolved og at det st?r en bra beskrivelse av hvordan den ble lukket, slik at dette kan benyttes som erfaringsdata for lignende saker fremover. Som standard g?r det en melding til kunde (requestor) om at saken er lukket. Bruk reply under l?sning av saken dersom du ?nsker ? holde kunden orientert om det som skjer gjennom hele saken.

 

4.12) H?ndtering av spam i RT

Klikk p? IsSpam om du er sikker p? at en sak er spam. Om du er i tvil flytter du saken til k?er spam.suspects og overlater resten til Houston. IsSpam f?rer til at saken flyttes til en k? der du antakelig ikke har adgang, og derfor f?r en kryptisk melding om at du ikke har adgang til saken. IsSpam knappen finner du ?verst til h?yre p? skjermen:

 

 

4.13) Prioritering, varsling, purring og eskalering av saker

4.13.1) Frister

Hver k? i RT har sin egen startverdi p? tidsfristen for behandling av saker. Vi har valgt ? anbefale at de fleste k?er i RT har 8 dager som startverdi p? tidsfrist for ferdigbehandling av saker. Men k?sjefene kan velge sette opp sin k? med en annen frist som startverdi.

I forbindelse med saksbehandlingen kan hver enkelt sak f? satt sin egen tidsfrist, ved ? sette dato og eventuelt tidspunkt for utl?p av fristen. Fristen b?r ligge mellom 3 dager og 3 uker, dersom opplegget for prioritering, eskalering og purring i RT skal fungere brukbart.

 

4.13.2) Prioritering

For hver k? velges en prioriteringsskala med startprioriteten og h?yeste prioritet i omr?det 1-99. I avsnittet nedenfor er det forklart hvordan prioriteten med tiden automatisk stiger fra startprioriteten til h?yeste prioritet, fram til dagen f?r sakens tidsfrist utl?per.Vi har valgt ? anbefale at alle k?er i RT settes opp slik at startprioriteten er 1 og h?yeste prioritet er 99 for alle saker. Men k?sjefene kan velge sette opp sin k? med en annen h?yeste prioritet som startverdi.N?r en sak ?pnes skal saksbehandleren vurderer sakens prioritet og velger en ny h?yeste prioritet for saken, som vist i tabellen nedenfor. Samtidig vurderes og settes vanligvis sakens tidsfrist.

 

 

 

Ikke vurdert
99
Prioritering er ikke vurdert av saksbehandler eller lignende
Lav
20
Problemet gir litt plunder og heft, men kan omg?s
Middels
40
Problemet gir noe plunder og heft, men kan omg?s
H?y
60
Problemet gir mye plunder og heft, men kan omg?s
Kritisk
80
Problemet kan ikke omg?s og stopper deler av kundens jobb
Fatal
99
Problemet kan ikke omg?s og stopper kundens arbeid helt

 

 

4.13.3) Varsling

Saksbehandlere (for eksempel den som har ukevakt) og den som er ansvarlig for k?en, m? selv s?rge for ? oppdage viktige begivenheter, for eksempel at en ny sak har kommet i k?en. Dette kan gj?res i RT eller eventuelt ved ? sette seg selv opp som QueueWatcher (i de aktuelle ukene) for den aktuelle k?en.

Vi har valgt ? sette opp RT slik at saksbehandleren automatisk varsles med e-post n?r han/hun er satt p? som owner i en sak, selv om dette f?rer til en del un?dvendig e-post for de som bruker RT mye.

K?eier f?r varsel om saker i k?en som er over due-date.

 

4.13.4) Purring

Vi har valgt ? sette opp RT slik at det hver natt sendes purring p? alle ?pne saker med prioritet over 50, og alle nye saker med prioritet over 40. Purring sendes som e-post til sakens eier/saksbehandler. For saker som ikke har f?tt eier sendes purring til k?sjefene. Vi har valgt ? sette opp RT slik bare saker som er nye eller ?pnet purres p? denne m?ten. I tillegg purres saker med status ”stalled” en gang hver m?ned. Tabellen nedenfor viser n?r purring sendes p? saker med ulik prioritet og tidsfrist.

At en sak har ligget over tidsfrisen, eller at en sak ikke har f?tt tildelt saksbehandler, f?rer i seg selv ikke til at RT sender purring p? saken. Legg merke til at en ny (ikke ?pen) sak kan ha saksbehandler, og at en sak uten saksbehandler kan v?re ?pnet!

 

4.13.5) Hvordan eskalere en sak

Vi har satt opp RT slik at prioriteten beregnes hver time p? alle saker i alle k?er.

Med en sak som har startprioritet 1, sluttprioritet 99 og tidsfrist p? 8 dager, vil prioriteten eskaleres med 14 hver dag, slik: 1, 15, 29, 43, 57, 71, 85 og 99, med mindre sakens prioritet endres manuelt underveis. Med forskjellige prioriteter p? saken, betyr dette at purring p? saken sendes ut som tabellen nedenfor viser:

Prioritet, betegnelse
H?yeste prioritet
Frist, dager
Dager til purring*)
Ikke vurdert
99
8
3 / 4
Lav
20
8
8
Middels
40
8
8
H?y
60
8
5 / 6
Kritisk
80
8
4 / 5
Fatal
99
8
3 / 4

 

 

*) For eksempel betyr 3 / 4: purring sendes etter 3 dager p? nye saker og etter 4 dager for ?pne saker.

Det fremg?r at vi har satt opp RT slik at alle saker der prioriteten ikke er vurdert, behandles som saker med prioritet ”fatal”.

Tidsfrister p? under tre dager passer d?rlig med dette opplegget for prioritering, eskalering og purring. Grunnen til dette er at prioriteten da n?r sluttverdien dagen etter at saken er opprettet. For eksempel blir purring ved prioritet 40/50 meningsl?s.

 

Eskalering av saker i linjeorganisasjonen

RT har ikke noen hjelpemidler p? dette omr?det. Det kan v?re aktuelt ? eskalere en sak i linjeorganisasjonen for eksempel dersom saken har ligget langt over tidsfristen, dersom kunden har klaget p? saksbehandlingen eller dersom kunden ?nsker ? anke saken. Alt slikt m? h?ndteres uten bistand fra RT.

 

4.14) Logge ut

Av sikkerhetsmessige hensyn er det viktig at du logger ut n?r du ikke skal bruke RT lenger. Velg menyen Logout ?verst i h?yre hj?rne i skjermbildet, denne menyen er alltid tilgjengelig uansett hvilke oppgaver du jobber med.

 

5) Avanserte funksjoner for saksbehandler

5.1)  Relasjoner i RT

Relasjoner (Relationships) inkluderer depends on, depended on by, parents, children, refers to og referred to by. Relasjonene kalles ofte for links i RT. Det er satt opp relasjoner for hver sak, og for ? se hvilke relasjoner som gjelder for den aktuelle sak klikker du p? Links p? venstre side i saksskjermbildet. Du kan legge til relasjoner, fjerne relasjoner eller duplikater i dette skjermbildet. Husk ? klikke p? Save Changes for ? f? lagret endringene.

P? bildet under er vi inne p? en sak og har allerede gjort den avhengig av en annen sak ved ? bruke "Depends on" under New Links. Her skrev man inn ticket nummeret til saken man ville gj?re den saken vi jobber med avhengig av.

 

 

 

5.2) Hvordan generere rapporter fra RT

Du kan lage rapporter i RT ved ? s?ke p? ulike felt. For eksempel kan du f? ut oversikter over alle saker som har en bestemt saksbehandler, alle saker som har en type status, alle saker som ikke er lukket innenfor en gitt tidsangivelse med mer, alle saker innenfor en bestemt kategori eller tema med mer. Disse rapportene kan tas ut ved bruk av s?kemulighetene i RT.

 

5.3) Hvordan hente ut statistikk fra RT

Det finne to vidt forskjellige m?ter ? gj?re dette p?.

  1. Du kan som saksbehandler, hente ut rapporter. Denne funksjonaliteten ligger under Tools>Reports.
  2. For hvert s?k som du utf?rer, enten det er et manuelt eller autmatisk (lagret) s?k kan du hente ut statistikk p? resultatene (se bunnen av nettsiden n?r du sitter og ser p? resultatet av s?ket).

 

5.4) Administrering av saker ved bruk av e-post

Dette er en tilpasning som er laget for UiO og som gj?r det mulig ? oppdatere saksattributter ved bruk av e-post. Det kan for eksempel benyttes til ? oppdatere eiere av saker eller endring av k?. Dette kan benyttes n?r en ny sak opprettes eller endres.

Informasjonen som f?lger baserer seg p? den til n? (primo desember 2006) nyeste publiseringen av hvilke funksjoner som er implementert i RT. Noen av de siste funksjoner som har v?rt etterspurt er opprettelsen av "link" og "custom fields". Informasjonen som er limt inn under her, kommer fra: http://www.cpan.org/authors/id/J/JE/JESSE/RT-Extension-CommandByMail-0.05.readmeMerk! Det er ingen kontroll p? feil ved bruk av e-post, e-posten blir ignorert hvis den inneholder feil i ett eller flere felt. Slik e-post kan ikke ha vedlegg.Implementeringen baserer seg p? bruk av pseudo-felt. Her er en oversikt som viser hva som kan benyttes. Felt i parentes er ikke implementert i l?sningen forel?pig.****

  COMMANDS
   Basic
    Queue: <name>
        Set new queue for the ticket

    Subject: <string>
        Set new subject to the given string

    Status: <status>
        Set new status, one of new, open, stalled, resolved, rejected or
        deleted

    Owner: <username>
        Set new owner using the given username

    Priority: <#>
        Set new priority to the given value

    FinalPriority: <#>
        Set new final priority to the given value

   Dates
    Set new date/timestamp, or 0 to unset:

        Due: <new timestamp>
        Starts: <new timestamp>
        Started: <new timestamp>

   Time
    Set new times to the given value in minutes. Note that on
    correspond/comment "TimeWorked" add time to the current value.

        TimeWorked: <minutes>
        TimeEstimated: <minutes>
        TimeLeft: <minutes>

   Watchers
    Manage watchers: requestors, ccs and admin ccs. This commands can be
    used several times and/or with "Add" and "Del" prefixes, for example
    "Requestor" comand set requestor(s) and the current requestors would be
    deleted, but "AddRequestor" command adds to the current list.

        Requestor: <address> Set requestor(s) using the email address
        AddRequestor: <address> Add new requestor using the email address
        DelRequestor: <address> Remove email address as requestor
        Cc: <address> Set Cc watcher(s) using the email address
        AddCc: <address> Add new Cc watcher using the email address
        DelCc: <address> Remove email address as Cc watcher
        AdminCc: <address> Set AdminCc watcher(s) using the email address
        AddAdminCc: <address> Add new AdminCc watcher using the email address
        DelAdminCc: <address> Remove email address as AdminCc watcher

   Links
    Manage links. These commands are also could be used several times in one
    message.

        DependsOn: <ticket id>
        DependedOnBy: <ticket id>
        RefersTo: <ticket id>
        ReferredToBy: <ticket id>
        Members: <ticket id>
        MemberOf: <ticket id>

   Custom field values
    Manage custom field values. Could be used multiple times.

        CustomField.{C<CFName>}: <custom field value>
        AddCustomField.{C<CFName>}: <custom field value>
        DelCustomField.{C<CFName>}: <custom field value>

    Short forms:

        CF.{C<CFName>}: <custom field value>
        AddCF.{C<CFName>}: <custom field value>
        DelCF.{C<CFName>}: <custom field value>

****
 

Eksempel p? en e-post der disse pseudofeltene er benyttet:

From: Mari Wang

To: test@rt-dev.uio.no

Subject: Testing pseudo headers
Owner: mari
Status: open
Due: 2022-09-01
Starts: 2022-08-01
Started: 2022-07-03
AddRequestor: mari@some.domain
AddCc: mariwan@some.domain
AddCc: mariwang@some.domain
AddAdminCc: mariwang@some.domain
Priority: 50
FinalPriority: 90

6) Oppsett av RT - RT at a glance

6.1) Tilpassing av din innloggingside: "RT at a glance"

N?r du, som saksbehandler, har logget inn p? RT (via f.eks. rt.uio.no) kommer du inn til din personlige hjemmeside i RT. Hva som skal komme til syne p? denne innloggingssiden bestemmer du selv og den heter "RT at a glance". Ikke bare bestemmer du hvilke innholdsbokser som skal komme fram, men innholdet i boksene kan alts? v?re resultatet av s?k som du selv har laget. Poenget er at du raskt skal f? tak i den informasjonen som du trenger i din hverdag som saksbehandler. TIPS: sett av noen minutter og gj?r deg kjent med det som beskrives under. Du vil da spare tid i din fremtidige bruk av RT.  

 

6.2) "Mine preferanser"

Alle saksbehandlere som logger seg p? RT har muligheten til ? stille inn sine egen preferanser. Du finner linken til disse innstillingene enten p? den ?verste linkraden i navigasjonspaletten eller helt oppe til h?yre i vinduet.

 

 

Dine innstillinger handler om egenskaper ved din bruker som kommer til syne i forskjellige settinger i RT. Det finnes 5 valg innen preferences hvor vi skal se spesielt p? ABOUT ME og SEARCH OPTIONS.

 

 

ABOUT ME: Ditt ekte navn, kallenavn (nickname), ytterligere telefonnumre, adresse, signatur p? meldinger fra deg. Deler av dette hentes automatisk fra LDAP og kan ikke endres av brukeren. Hvis du pr?ver ? overstyre informasjonen vil den returnere til det som kommer fra LDAP ved neste oppdatering, s? det har ingenting for seg ? fylle ut denne informasjonen.

 

SEARCH OPTIONS er sv?rt viktig.

 

 

De innstillingene du gj?r her blir til standardvalgene dine for hvordan du ?nsker ? fremstille resultater p? s?k i hele RT. S? hvis du har sterke ?nsker for om korrekt sortering av saker er at de nyeste skal f?rst eller de gamle skal f?rst, s? er dette definitivt stedet ? si ifra om dette. N?r du seinere lagrer automatiske s?k som skal komme tilsyne i f.eks. din egen RT at a glance s? vil standardvalget ta utgangspunkt i det du har satt opp her under PREFERENCES>SEARCH OPTIONS.

PERSONAL GROUPS og DELEGATION er forel?pig ikke tatt i bruk i v?r l?sning for UiO.

RT AT A GLANCE er det samme som ? trykke p? edit for ? redigere sin egen forside. Se "redigering av body og summary" rett nedenfor.

 

6.3) Redigering av skjermarealene Body og Summary

Det st?rste arealet kalles body og er et ubegrenset bokser under hverandre som dekker nesten hele bredden p? skjermen.

 

 

B?de i body og summary kan du alts? bestemme hvilke vinduer som skal vises. I tillegg blir du best om ? bestemme omfanget av disse arealene.

Klikk p? Edit som st?r i bl?tt ut til h?yre for menyen til RT at a glance.

 

 

Da ?pnes muligheten til ? slette eller bytte innholdet i body og summary. I firkanten som heter available ligger alle varianter av bokser som du kan ha opp i body. Klikk p? de(n) du vil ha framme p? din f?rsteside. Deretter klikker du p? den h?yrerettede pilen mellom available og listen over de du allerede har valgt. Gj?r det samme for summary.

 

 

NB: V?r anbefaling er at du fjerner Quick create siden denne funksjonen ikke passer inn i UiOs n?v?rende l?sning og derfor kun tar opp viktig plass p? din egen RT at a glance.

Helt nederst p? siden velger du hvor mange saker som skal komme til syne f.eks. innen samme k?. Du kan selv skrive inn det tallet som passer deg.

 

 

6.4) Direkte redigering av hver enkelt boks p? f?rstesiden

Den oppmerksomme ser at det er en egen editknapp p? mange av boksene som finnes p? f?rstesiden "RT at a glance". N?r du klikker p? denne kommer du rett til visningsegenskapene for akkurat denne boksen. F.eks. visning av "Alle saker jeg jobber med" under body-delen vist p? bilde under.

 

 |

N?r du klikker p? denne knapper kommer du alts? tilbake til innstillingene som kun gjelder visning av k?ene (se forklaring p? dette litt lenger ned)

 

6.5) Andre egenskaper som redigeres(My Tickets, Unnowned tickets og  Quick Search)

 

 

1) My Tickets

"My Tickets" under Customize RT at a glance vil si ? redigere hvilke av sakens egenskaper som skal komme til syne dersom den skal vises i body/symmary. N?r du ?pner selve saken vil du selvf?lgelig se alle egenskaper til saken, men det er ikke plass til det p? kortlistene som skal gi deg et kjapt overblikk. Derfor blir du bedt om ? velge hva som skal v?re med i kortoversikten, samt hvilke egenskaper sakene skal sorteres etter, osv osv. Du kan for eksempel velge p vise bokmerker i en egen kolonne.

 

 

2) Unowned Tickets

N?r du skal velge hvordan "Unowned tickets" skal komme til syne f?r du de samme valgene som under My Tickets. Et tips kan f.eks. v?re ? velge bort en del egenskaper p? saker som ikke er dine.

3) Quick search

I denne kolonnen velger du hvilke k?er som skal komme tilsyne i listen over k?er. Denne listen er ofte en natulig del av "at a glance" siden, og hjelper deg ? hoppe raskt fra k? til k?, dersom du er saksbehandler i flere k?er. Benytt sjansen til ? fjerne k?er du ikke har noe med ? gj?re.

 

 

6.6) Brukerrettigheter og grupper

RT har et stort opplegg for h?ndtering av brukerrettigheter. Det er totalt over 81 ulike rettigheter som kan gjelde enten for hele RT (global), for en gitt k? eller en gitt gruppe av brukere. Dette opplegget overg?r langt det UiO har behov for.

6.6.1) Kunder

Til hver k? skal det med enkelte unntak v?re en gruppe av brukere som kan sende saker til k?en. Normalt vil vi for dette form?let bruke systemgruppen ”Everyone”, dersom k?en skal v?re ?pen for alle brukes.

6.6.2) Saksbehandlere

Til hver k? skal det v?re en gruppe av saksbehandlere. For mange av k?ene til USIT er det per idag (nov 2006) én felles gruppe av saksbehandlere: "rt-saksbehandler"

6.6.3) K?sjefer

Som tidligere nevnt skal hver k? ha minst to k?sjefer.

6.6.4) Watchers

B?de brukere (uprivilegerte) og saksbehandlere (privilegerte) kan opptre som Watchers, p? en utvalgt sak eller p? en utvalgt k? i sin helhet. RT har to typer Watchers som heter Cc og AdminCc. Sistnevnte f?r kopi av all e-post som gjelder den aktuelle saken, eller alle sakene i den aktuelle k?en. Cc f?r i likhet med kunden (Requestor) kopi av all e-post unntatt kommentarene.

Det er bare saksbehandlere p? den aktuelle k?en som kan sette opp eller fjerne noen som Watcher p? enkeltsaker i k?en. En Watcher som er privilegert kan i RT hente opp de sakene han/hun er Watcher p?, samt alle saker som h?rer til k?er han/hun er Watcher p?. Hun kan ikke hente noen andre saker i RT, eller se noen k? i sin helhet, med mindre han/hun er saksbehandler p? den aktuelle k?en.

En Watcher som er uprivilegert f?r bare se selvbetjeningsbildet i RT, og kan der hente opp de sakene han eller hun er Watcher p?, samt alle saker som h?rer til k?er hun er Watcher p?. Hun kan ikke hente noen andre saker, eller se noen k? i sin helhet, og sakene kan bare hentes ved ? oppgi saksnummeret. Det er ingen s?kemuligheter. Det er bare Requestor som f?r en liste av sine egne saker i selvbetjeningsbildet, mens andre uprivilegerte m? oppgi sakens nummer for ? f? se saken de er Watcher p?.

 

7) Rutiner i RT

7.1) Fordeling av saker p? saksbehandlere

Det understrekes at hver k? skal ha minst to k?sjefer (selv om det ikke etableres en egen gruppe av k?sjefer i RT). Det er k?sjefenes ansvar ? s?rge for at det skjer en fordeling av saker til saksbehandlerne. Det er ogs? k?sjefenes ansvar ? s?rge for at rutinene for saksfordeling er velkjent blant saksbehandlerne. Slike rutiner kan utformes p? forskjellige m?ter, her er to alternativer:

7.1.1) Alternativ 1, ukevaktordning

 (eller lignende): K?en har en ordning med rullerende ukevakter. Fungerende ukevakter har ansvaret for ? behandle alle innkomne saker, eller fordele utvalgte saker til andre dersom hun ikke kan ta alle sakene selv. K?sjefene har ansvar for ? sette opp vaktliste og f?lge opp at alle saker blir fordelt og behandlet i tide.

7.1.2) Alternativ 2, k?sjefer:

K?en har to eller flere sjefer som har ansvaret for ? fordele saker p? saksbehandlerne. K?sjefer og ukevakter vil normalt ha RT oppe hele tiden for ? f?lge med p? hva som kommer av nye saker og lignende. De som ikke ?nsker dette kan f? tilsendt all e-post for den aktuelle k?en ved ? sette seg opp som QueueWatcher (i de aktuelle ukene), for den aktuelle k?en.

7.2) Ansvar for vedlikehold av brukergrupper

Det er etablert ulike brukergrupper i RT, avhengig av hvilken funksjon som skal utf?res i systemet. Gruppene er k?sjefer, saksbehandlere og gruppe med lesetilgang.
*Noen brukergrupper vedlikeholdes i RT
*Noen brukergrupper vedlikeholdes ved at de synkroniseres mot nettgrupper

7.3) Flytting av saker mellom k?er

Det kan hende du som saksbehandler har behov for ? flytte saker til andre k?er.

  • Er du saksbehandler i den nye k?en som saken blir flyttet til kan du bare ta over saken i denne k?en
  • Har du ikke adgang til k?en som du flytter saken til m? du la saksbehandlerne i den nye k?en ta over saken som om den kom som en ekstern henvendelse

I det saken kommer over i k?en der saksbehandleren ikke har adgang blir saken borte fra skjermen og det kommer en melding som sier at man ikke lenger har adgang til saken

8) Forklaring av ord og uttrykk

Sak (Ticket)

Sentralt objekt i RT som har metadata som eier, status, k?, osv. tilknyttet seg.

 

K? (Queue)

Den sentrale administrative enheten i RT som holder ting organisert. En k? er en organisert rekke med saker som st?r for tur til ? bli l?st av en saksbehandler.

 

Sakshistorikk (Ticket's history)

Kommentarer om en sak (lagret permanent), dvs. alt som skjer om en sak.

 

Saksoppdateringer (Ticket updates)

Best?r av to varianter:

  • Svar (Reply) - Offentlig notat som kunden kan se
  • Kommentar (Comment) - En privat notat kun synlig for administratorer/saksbehandlere

 

Prioritet (Priority)

Hvor viktig en sak er - representert i en skala fra 0-99 (h?yeste). Policy m? lages.

 

Status listemeny (Status Drop-Down Meny)

For ? klassifisere en sak:

Ny (New)

- ur?rt sak

?pen (Open)

- saken er under arbeid

Lagt p? vent (Stalled)

- Eksempel: sakens kunde er p? ferie

Lukket (Resolved)

Forkastet (Rejected)

- ikke relevante saker, men ligger i basen som erfaringsdata

Slettet (Deleted)

- spam, skulle aldri v?rt i systemet i det hele tatt

Overv?ker (Watcher)

En som er interessert i en sak, og en overv?ker har flere typer roller:

Saksbehandler (Owner)

- den som har ansvaret for saken og at den blir l?st og lukket

 

Kunde (Requestor)

- den som har opprettet saken

Cc

noen som b?r f? en kopi av besvarelser (replies) som g?r til kunden

 

Privilegert bruker (saksbehandler og lignende) – (Staff user)

 

Uprivilegert bruker (kunde) – (Non-staff user)

 

AdminCC

- f?r kopier av alle kommentarer og generelt sett har tillatelse til ? jobbe med en sak

 

Relasjoner (Relationship)

I RT er dette sak-til-sak, men det kan ogs? v?re lenker til eksterne ting som URLer eller f.eks. fraktnummer osv.

 

Avhenger av (depends on)

- Saken kan ikke l?ses hvis ikke en annen sak blir l?st og lukket f?rst, motsatt er saker som har avhengigheter til (depended on by)

 

Refererer til (refers to)

- en sak trenger ikke en annen sak, men det er lurt/nyttig ? se p? en annen sak som denne refererer til, motsatt er (referred to by)

 

Fleksifelter (Custom Fields)

Databasefelter som din organisasjon kan f? satt opp etter behov.

 

Scripts

Skreddersydde meldinger som automatisk vil gj?re en handling X som respons til en handling Y. Innebygd i RT er det ?tte globale scrips, disse m? tilpasses UiOs installasjon. Det er ogs? mulig ? definere egne scrips. Scrips h?ndteres ved UiO av de som drifter og administrerer systemet.

 

9) Mer informasjon

Hjemmesiden til Best practical: http://www.bestpractical.com/

 


 

Publisert 21. juni 2010 09:52 - Sist endret 31. mars 2022 14:09