Rutiner for systemadministrasjon


1. Etablering av ny kø

… med tilhørende e-postadresser, brukergrupper/brukerrettigheter/egne datafelt etc.. Oppretting av en nye køer styres av tjenestegruppa for RT på grunnlag av mottatt søknad om etablering av en ny kø. Jobben har følgende hovedpunkter, med ulike ansvarlige til å gjøre hver sin del av jobben, og gjøres i nevnte rekkefølge: 

# Hvem? Hva?
1 Linjeleder der køen skal brukes, og de som skal bli køsjefer for køen Søknad om etablering av en ny kø fylles ut og sendes request-tracker@rt.uio.no. Tjenestegruppa for RT kan bistå ved utfylling av søknaden. Søknaden gir tjenestegruppa den informasjonen som trengs for å etablere den nye køen
2 Køsjefer, saksbehandlere og andre medlemmer av brukergrupper tilknyttet køen Dersom køens grupper ikke skal synkroniseres mot nettgrupper, må brukerne som (manuelt) skal legges til være opprettet som brukere i RT.  Disse etablerer seg automatisk som RT-bruker ved å sende en melding til general@rt.uio.no.
3 Tjenestegruppa for RT Køens gruppe av saksbehandlere etableres som en nettgruppe (Spread: NIS_ng@uio), med rt-drift og aktuell lokal-IT som moderatorer.  I særtilfeller benyttes ikke nettgruppe, og medlemmer legges manuelt til i RT.  Dersom det allerede finnes en nettgruppe som perfekt dekker behovet for saksbehandlere, kan denne brukes.  Tilsvarende gjelder for andre brukergrupper tilknyttet køen.
4 Tjenestegruppa for RT Køen etableres i RT og testes, men aktiveres ikke,
5 Køsjefer Medlemmene i køens gruppe av saksbehandlere settes opp manuelt, med mindre gruppen synkroniseres mot en nettgruppe eller køen skal bruke en eksisterende gruppe av saksbehandlere. Og tilsvarende for andre brukergrupper tilknyttet køen
6 Saksbehandlere RT-kurs for nye saksbehandlere, der det er aktuelt
7 Postmaster Køens e-postadresser kobles opp, på et tidspunkt som velges ut fra hensyn til når det passer å skifte fra en eksisterende e-postliste (der det er aktuelt) til å gjøre saksbehandling i RT. Fra da av går all e-post til den nye RT-køen i stedet for tidligere e-postliste (selv om køen fortsatt er deaktivert)
8 Tjenestegruppa for RT Køen og tilkoblingen av e-post testes, og tilslutt aktiveres køen. Det bør gå minst mulig tid mellom dette og foregående punkt

Ved overgang fra e-postliste til RT bør oppdragsgiver gjøres oppmerksom på at de første sakene i den nye køen kan ha en forhistorie i e-postsystemet.


2. Etablering av malsvar

Før malsvar kan tas i bruk må kunde besvare alle spørsmål i søknadsskjema for malsvar

  • Det opprettes først en klasse som vil inneholde artiklene kunden etterhvert oppretter. Klassen knyttes til en kø, evt. flere køer, og artikler vil da være tilgjengelig i denne/disse køen(e). Etter at klasse er opprettet vil man konfigurere den ved å knytte artikler i klassen til det egendefinerte feltet Artikkel_tekst som vil inneholde tekst i artiklene, definere emneliste som artikler skal sorteres under (dersom dette ønskes) samt sette rettigheter.
     
  • Klassen skal ha samme navn som køen og i tilfeller hvor det er snakk om flere køer, vil man forsøke å finne et passende navn for klassen som ligger tett opp mot navnestandard for køene. Da vil det være hensiktsmessig å navngi klassen mer generelt i henhold til enhetsbenevnelse og funksjon og ikke direkte etter kønavn. Eksempelvis dersom HF-IT ønsker en klasse for flere av sine køer som begynner med hf-it-kønavn, vil naturlig navn på klassen være hf-it.

Brukerveiledning malsvar.


3. Nedlegging av kø

Anta at køen har navn x-y. Da har den alltid de to adressene:

  • x-y@rt.uio.no
  • x-y-comment@rt.uio.no

Disse to adressene nedlegges alltid sammen med køen (som del av punk 3 nedenfor).

  1. Alle saker i køen avsluttes (til status: 'resolved', 'rejected' eller 'deleted')
  2. Dersom en (eller flere) av køens adresser skal kobles over på en e-postliste må denne lista (gjen-)opprettes først, og adressen kobles over fra kø til e-postliste av Postmaster
  3. For hver av køens øvrige adresser vurderes om den skal nedlegges eller omkobles til en annen kø, e.l. Slik omkobling må gjøres først, via Postmaster, for å hindre at det kommer meldinger til en nedlagt kø i RT
  4. Fra Postmaster bestilles deaktivering av køen og alle dens gjenværende adresser
  5. For alle saker i køen har vi følgende alternativer:
    • sakene blir liggende der de er, for senere arkeologiske utgravinger
    • eller sakene flyttes til en annen kø for arkivering/ferdigbehandling (NB, her har vi spesielle tiltak for å hindre at  det går melding til sakens aktører for hver sak som flyttes, se kapittel 6 nedenfor)
    • eller slettes
  6. Om køen har egne 'Templates' eller 'Scrips' slettes disse
  7. Egne datafelt til køen deaktiveres, om man er sikker på at det aktuelle felt ikke brukes av en annen kø også
  8. All synkronisering mellom nettgrupper og køens brukergrupper stoppes
  9. Eventuelle nettgrupper tilknyttet den aktuelle køen nedlegges av LITA, om de ikke brukes for andre formål også
  10. Alle brukergrupper (…-owners, -saksbehandler, -innsyn, -kunder) tilhørende køen tømmes for medlemmer og deaktiveres i RT, om man er sikker på at den aktuelle gruppen ikke brukes av en annen kø også
  11. Køen deaktiveres i RT og dens 'Reply Address' og 'Comment Address' slettes (til 'default')
  12. Eventuelle adresse til køen som er i RTAddresses.txt strykes fra denne listen
  13. Alle saksbehandlere på køen må gjøres oppmerksom på følgende: Eventuelle lagrede søk som bruker køen vil ikke lenger fungere som før køen ble nedlagt

4. Endre navn på kø

… gjøres ved først å opprette en ny kø med det nye navnet og deretter nedlegge den gamle. Anta at en kø med navn x-y (her omtalt som "den gamle køen") skal skifte navn til q-z (her omtalt som "den nye køen"), og at køoppsettet ellers ikke skal endres på noe punkt. Den gamle køen har alltid to adressene:

  • x-y@rt.uio.no
  • x-y-comment@rt.uio.no

(Men, vanligvis har køen flere adresser enn dette.) Disse to adressene kan ikke kobles til en kø med noe annet navn enn x-y. Dette gjør det praktisk vanskelig å skifte kø-navn for køer der disse adressene er publisert og i aktiv bruk. Sistnevnte adresse brukes normalt bare av RT selv, og indirekte bare av RT saksbehandlere, så det gjør ikke så mye om den forsvinner i forbindelse med at køen bytter navn. Dersom den første av de to adressene er i aktiv bruk, f.eks. som køens primæradresse, kan køen i realiteten ikke skifte navn før adressen kan slettes fra e-postsystemet til UiO. Derfor gjøres navnendringen slik:

  1. Det opprettes en ny kø med navn q-z og tilsvarende oppsett som køen x-y, dog slik at:
    • brukergrupper i RT der x-y inngår i navnet endres slik at q-z inngår tilsvarende (Husk at brukergruppen q-z-owners brukes i RT for å sende purringer til køsjefer)
    • for nettgrupper tilknyttet disse brukergruppene kan det være aktuelt å gjøre tilsvarende navnendringer
    • tilsvarende gjøres for navn på egne datafelt, 'templates', 'scrips' etc, der det er aktuelt
    • lagrede søk der x-y inngår endres til søk der q-z inngår tilsvarende
  2. Den nye køen overtar alle adresser som leder til den gamle køen, unntatt de to som er nevnt ovenfor, og den gamle køen bruker eventuelt x-y@rt.uio.no midlertidig som primæradresse
  3. Alle saker i x-y flyttes over til q-z (se kapittel 10 nedenfor)
  4. Køen x-y med tilhørende adresser etc nedlegges (se kapittel 2 ovenfor), så snart men kan være sikker på at den gamle adressen x-y@rt.uio.no ikke har noe trafikk

Om adressen x-y@rt.uio.no ikke kan slettes bør det være et alternativ å la køen x-y leve som den er til den får en "naturlig" død. Som et "biprodukt" av denne rutinen ser vi at adressene på formen x-y@rt.uio.no helst ikke bør publiseres, siden dette vanskeliggjør et eventuelt senere skifte av navn på køen. Alle saksbehandlere på køen må gjøres oppmerksom på følgende: Eventuelle lagrede søk som bruker køen må sjekkes for å fastslå om søket fortsatt fungere som forventet etter køens navnendring.


5. Ny/endret køadresse

Kobling av adresser til køer bør bestilles fra request-tracker@rt.uio.no, og ikke direkte fra Postmaster. Grunnen er at endringer må registreres både i RT og i e-postsystemet. Hver kø har minst to e-postadresser:

  • Reply-adressen
  • Comment-adressen

For sistnevnte adresse har UiO valgt fast format (x-y-comment@rt.uio.no når kønavnet er x-y), og denne adressen kan ikke endres. Reply-adressen brukes til innsending av saker og som avsenderadresse for RT. Denne kan endres, og endringsforslag sendes til RT tjenestegruppa på request-tracker@rt.uio.no.

I tillegg kan hver kø ha flere adresser for innsending av saker. Disse kan endres etter søknad til tjenestegruppa. RT har ikke verktøy for å vise hvilken adresse som ble brukt for å sende inn en gitt sak/melding, men dette vil fremgå dersom man i RT velger 'Full headers' for den aktuelle saken.

En kø med navn x-y har alltid x-y@rt.uio.no som en av sine gyldige adresser, enten som primæradresse eller i tillegg. Du kan slå opp i BOFH for å se alle adresser knyttet til køen slik: jbofh> email info x-y@rt.uio.no


6. Opprette egne datafelt

RT har mulighet for å ha egne datafelt tilknyttet sakene i en kø. Alle saker i en kø har de samme datafeltene. Datafeltene kan være av ulik type, og de vanligste er rene tekstfelt og nedtrekksmenyer. Egne datafelt settes opp felles for alle køer, men for hver kø fastsettes hvilke av feltene som er i bruk. Oppsett og endring av egne datafelt kan gjøres for alle køer, også de som er i bruk. Oppretting av datafelt og kobling av disse til køer, kan bare gjøres av tjenestegruppa for RT.


7. Opprette ny brukergruppe med tilhørende rettigheter

Dette kan bare gjøres av tjenestegruppa for RT. Send forespørsel til request-tracker@rt.uio.no. Se eget dokument om brukerrettigheter i RT. Ved UiO har vi til nå etablert 3 typer grupper, med tilhørende rettigheter i RT:

  • Køsjefer for en gitt kø
  • Saksbehandlere på en gitt kø
  • Folk med innsynsrettigheter på en gitt kø

8. Egen automatisk melding for kø

8.1 Reformulering av autosvar

Som eksempel brukes her den automatiske meldingen ved oppstart av ny sak. Lag en ny 'Template' for oppstartmeldingen til køen ved navn 'x-y'. Man kan ta utgangspunkt i global 'Template', men ikke fjerne eller endre noe på denne. Gjør slik:

  1. Gå til Tools ⇒ Configuration ⇒ Global ⇒ Templates ⇒ Select ⇒ Autoreply (eller tilsvarende)
  2. Kopier Name/Description/Content
  3. Gå til Configuration ⇒ Tools ⇒ Queues ⇒ Select ⇒ 'x-y' ⇒ Templates ⇒ Create
  4. Lim inn Name/Description/Content
  5. Juster feltet 'Description' f.eks ved å erstatte "Default" med "Local" eller tilsvarende
  6. Juster feltet 'Content' etter behov
    • Første linje ser normalt slik ut:
      "Subject:  Automatisk svar (AutoReply): {$Ticket->Subject}"
      og denne bør være med (antakelig uendret) for at autosvaret skal få et egnet 'Subject'
    • For ikke å "forstyrre" den tekniske strukturen i malen er det enklest om endringene er i form av ren tekst i starten av den norske del av meldingen og tilsvarende for den engelske delen
  7. Klikk på 'Create'
  8. Test den nye meldingen på nyetablert sak i kø 'x-y'. Påse at linjeskift er pene og at eventuelle URLer funker og ser ut som forventet

8.2 Utelate autosvar ved avslutning av sak

For å kutte ut den automatiske meldingen ved 'resolved' på saker, for en kø med navn 'x-y', gjør slik:

  1. Gå til Tools ⇒ Configuration ⇒ Global ⇒ Scrips ⇒ Select ⇒ 10
  2. Tilføye følgende linje i 'Custom condition', ordnet alfabetisk etter kønavn:
    return 0 if ($queue eq "x-y");
  3. Klikk på 'Save Changes'
  4. Test at det ikke kommer noen automatisk melding ved 'resolved' på saker i den aktuelle køen
  5. Tilslutt testes at en kø der det skal komme melding ved 'resolved' fortsatt har dette

9. Etablering av ny saksbehandler

Dette gjøres egentlig av køsjefene, men de trenger ofte bistand

  1. Få tak i brukernavn og e-postadresse. Om brukeren ikke har RT-konto oppfordres hun til å sende e-post til general@rt.uio.no
  2. Få tak i navn på den køen der vedkommende skal være saksbehandler
  3. Undersøk om køens gruppe av saksbehandlere er synkronisert mot en nettgruppe
    • om så er: lokal it-ansvarlig må melde brukeren inn i den aktuelle nettgruppen
    • dersom ikke: køsjefene henvises til punkt 1.2 i rutiner for køsjefer

10. Gul og rød info-boks

I bildet for RT pålogging er det mulighet for å sette opp en gul boks med ordinær informasjon til brukerne og en rød boks med kritisk informasjon til brukerne.

Når en ny melding skal legges ut foreslår vi følgende fremgangsmåte:

  1. Først legges meldingen ut på nettsiden "meldinger.htlm" med html-editoren i Vortex
  2. Eventuelle pekere settes opp med absolutte adresser
  3. Bruk knappen "Kilde" i editoren til Vortex og kopier de aktuelle deler av html-koden
  4. Limer dette inn i "messages-test.txt" eller "warn-test.txt" med txt-editoren i Vortex
  5. Etter eventuelle "<a " tilføyes: style="text-decoration: underline; "
  6. Fjern gamle meldinger fra boksene (den gule bør ikke overskrider 4 linjer med tekst)
  7. Legg til eller fjern "DO NOT SHOW" etter behov
  8. Gå inn på RT-test og se at begge boksene ser ut som de skal der (det kan ta opptil 15 minutter)
  9. Kopier til "messages.txt" eller "warn.txt" for å legge den nye meldingen ut i produksjon

Alt dette er felles for RT-instansene til SO og UiO.


11. Bytte av kø uten meldinger

RT sender automatisk meldinger til sakens aktører når en sak flyttes fra en kø til en annen. Dette kan bli slitsomt om man skal flytte mange saker. For å unngå disse meldingene kreves noen tekniske inngrep som gjøres slik:

  1. Send en e-postmelding til request-tracker@usit.uio.no for eksempel slik:
    • Søk for sakene som skal flyttes: Queue = 'x-y' AND Created > '2010-06-01'
    • Disse sakene skal flyttes til kø: 'q-z'
  2. Scriptet for flytting av sakene prøvekjøre, uten at sakene faktisk flyttes, men skrives ut på en liste
  3. Listen som er resultatet av prøvekjøringen granskes for å se at det er som forventet
  4. Scriptet for flytting av saker uten meldinger kjøres

12. Forebygge e-postløkker

For å hindre e-postløkker må man unngå at RT sender e-post til seg selv. Men med unntak av adressene på formen …@rt.uio.no kan man ikke av selve adressen se om den går til RT eller ikke. Derfor må alle adresser som leder til RT være med på listen RTAddresses.txt, unntatt de adressene som er på formen …@rt.uio.no. Send melding til request-tracker@usit.uio.no for å få endret denne adresselista.

Se eget dokument vedr stopping av pågående e-postløkker.


13. Se preferansene til en saksbehandler

Saksbehandlere kan sette opp RT etter individuelle behov (se egen artikkel om dette). For eksempel kan saksbehandler stenge av for mottak av e-post fra RT, for så etter en tid å glemme dette igjen og sende inn feilmelding om at RT ikke sender ut e-post til vedkommende. Det er en betydelig svakhet ved RT at systemadministrator ikke direkte kan se hvordan en gitt bruker har satt opp RT for seg selv. For å lette en del av denne situasjonen har vi laget et opplegg for å liste opp preferansene til en gitt bruker. Å gjøre dette krever en del teknisk innsikt, så du sender en melding til request-tracker@usit.uio.no og ber om å få listet opp preferansene til en gitt bruker.

For å få en komplett løsning på hele denne problemstillingen burde det være mulig for systemadministrator å logge seg på RT i en annen brukers navn, med rettigheter "se men ikke røre". Da kunne systemadministrator for eksempel se hvordan brukeren har satt opp sin "RT at a glance" etc.


 

Publisert 16. juli 2010 11:21 - Sist endret 4. apr. 2020 07:31