Administrasjon
Nosyko AS Rådhusgt. 17 0158 Oslo Telefon: 22 33 15 70 Telefaks: 22 33 15 75 Epost: [email protected] Web: www.drofus.no BRUKERVEILEDNING Versjon 1.1.8 ADMINISTRASJONSVEILEDNING Versjon: 1.7 DOKUMENTDATO: 2014-06-16 Nosyko AS Rådhusgata 17 0158 Oslo Epost: [email protected] Web: www.drofus.no Telefon: 22 33 15 70 ADMINISTRASJONSVEILEDNING Innhold 1. Innledning............................................................................................................................... 3 1.1. 2. Om dette dokumentet ................................................................................................................... 3 Administrasjonssystemet på web ....................................................................................... 4 2.1. 2.2. 2.3. 2.4. 2.5. Generelt.......................................................................................................................................... 4 Prosjektadministrator.................................................................................................................... 4 Databaseadministrator ............................................................................................................... 10 Brukeradministrasjon .................................................................................................................. 13 Forbedringer i brukerdetaljer....................................................................................................... 13 3. Innstillinger .......................................................................................................................... 15 4. TIDA ....................................................................................................................................... 17 4.1. 4.2. 4.3. 4.4. 4.5. 5. Dynamisk skjemaer (GUI) ................................................................................................... 23 5.1. 5.2. 5.3. 5.4. 6. TFM nummer og andre kjernedatavalg ....................................................................................... 17 Komponentforslag....................................................................................................................... 18 Velge hvilke tekniske data felter som skal vises (filter)............................................................... 19 Endringer i skjermbilder............................................................................................................... 20 Globale databasevariable ............................................................................................................ 21 Oppbygning av faner, grupper og felter ....................................................................................... 23 Endring av skjema........................................................................................................................ 23 Funksjonsprogram ...................................................................................................................... 28 RFP visningsfilter ......................................................................................................................... 28 Teknisk arkitektur og installasjon av drofus tjener ......................................................... 30 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. Innledning .................................................................................................................................... 30 Databasetjener ............................................................................................................................ 30 Rapport-/dokumenttjener........................................................................................................... 31 Klientprogram .............................................................................................................................. 31 Admininstrasjonssystem ............................................................................................................. 32 Administrasjon av tjener .............................................................................................................. 32 2 ADMINISTRASJONSVEILEDNING 1. INNLEDNING 1.1. Om dette dokumentet Dette dokumentet gir en innføring i administrasjon av prosjekter og databaser i dRofus. Tilgang til funksjonaliteten beskrevet i dette dokumentet gis vanligvis til en person på hvert prosjekt, eller den ivaretas av dRofus, særlig for mindre prosjekter. 1 Det forusettes at man kjenner godt til dRofus og innholdet av brukerveiledningen før man begynner å bruke administrasjonsfunksjonaliteten. Hvis du mangler et av disse dokumentene, vennligst last ned fra http://www.drofus.no/no/support-og-tjenester/brukerveiledninger/ NB: En del av de tingene som kan gjøres i administrasjonsdelen av programmet kan medføre tap av data. Det er ikke alltid det gis advarsel om dette så hvis du er usikker så kontakt Nosyko før du gjør endringer. Som bruker med administratorrettigheter har du tilgang til to tilleggsfunksjoner som vanlige brukere ikke har. Du vil få tilgang til en webbasert administrasjonstjeneste og du vil få en ny meny på hovedmenylinjen i dRofus kalt Administrasjon. I kapittel 2 tar vi for oss det webbaserte administrasjonssystemet, mens kapittel 3-5 handler om det man kan gjøre under Administrasjon menyen i dRofus. 1 Brukerveiledingen er dokumentet som beskriver all funksjonalitet i dRofus. Denne er tilgjengelig fra http://www.drofus.no 3 ADMINISTRASJONSVEILEDNING 2. ADMINISTRASJONSSYSTEMET PÅ WEB 2.1. Generelt Brukere med administrasjonsrettigheter har tilgang til to funksjoner som vanlige brukere ikke kapittel 3), og de har mulighet til å benytte en web basert administrasjonstjeneste for å administrere databaser og prosjekter. Vi skiller mellom to forskjellige nivåer i web administrasjonen; prosjektadministrator og databaseadministrator. 2.2. Prosjektadministrator Som prosjektadministrator har du mulighet til å opprette/slette brukere og sette brukerrettigheter for den enkelte bruker. Du vil kun få mulighet til å gjøre disse endringene i prosjekter hvor du har administratorrettigheter. Et eksempel på velkomstmenyen ser du på bilde under. Figur 1: Hovedmeny prosjektadministrator 4 ADMINISTRASJONSVEILEDNING Prosjekter Figur 2: Prosjektvisning og brukerliste tilgang til som administrator. Under hvert prosjekt kan du opprette nye brukere enten ved å om byggherre, beskrivelse, brutto areal, adresse og eier. Du kan også velge å gjøre prosjektet inaktivt. Brukere Her får du en oversikt alle brukere, ikke bare på dine prosjekter. Her kan du søke på både navn, brukernavn og e-post adresse. Ved å klikke på brukeren i listen får du frem info om navn, epost og hvilke prosjekter brukeren har tilgang til. Du kan fra dette vinduet legge til brukeren i et prosjekt som du har prosjektadministrator rettigheter til. Velg prosjekt fra nedtrekkmenyen post som gir en oversikt over hvilke prosjekter brukeren har tilgang til. Du kan også endre informasjon om brukeren evt. slette brukeren ved å bruke snarveiene til høyre i brukerlista. Legg til bruker klikke på snarveien til høyre for arealfeltet( ), eller du kan klikke deg inn på et prosjekt og å gå via brukerlisten, klikke på en bruker og legge han/hun til et prosjekt. 5 ADMINISTRASJONSVEILEDNING Figur 3: Legg til bruker og sett brukertilgang Under brukerdetaljer legger du inn informasjon om brukeren. Fornavn, etternavn og e-post er obligatoriske felter. Du vil merke at systemet automatisk søker frem brukere som matcher det navnet du taster inn. Hvis brukeren du skal legge til allerede har en log-in i et annet prosjekt vil brukeren komme frem som et alternativ under Eksisterende brukere som ligner. Systemet vil også automatisk generere et brukernavn basert på det du skriver inn som Fornavn og Etternavn. Dette kan justeres/endres manuelt om det er ønskelig. Legger du til et brukernavn som allerede eksisterer vil du få opp en feilmelding og du må endre brukernavnet. Under brukerrettigheter styrer du hvilke rettigheter brukeren skal ha innenfor de forskjellige modulene i dRofus. Ved å la muspekeren hvile over det blå spørsmålstegnet får du frem en ledetekst som forklarer hva de forskjellige rettighetene innebærer. MERK: Grensesnittet i dRofus vil endre seg etter hvilke moduler brukeren har tilgang til. Gi kun brukere tilgang til de modulene de skal benytte. Hvis en database inneholder flere prosjekter vil du få et valg om å legge til brukeren i alle prosjekter. Oppretting av prosjekt/database er forklart nærmere i kapittel 2.2. Du kan som prosjektadministrator sette en tidsbegrenset brukertilgang ved å bruke databaser for den valgte brukeren på serveren og ikke bare for det aktuelle prosjektet. 6 ADMINISTRASJONSVEILEDNING Til slutt velger du e-post format fra nedtrekkmenyen basert på hvilke moduler du gir brukeren tilgang til. Du kan også se en forhåndsvisning av e-posten ved å klikke på e-post ikonet. Til slutt har du to valg. Du kan enten legge til bruker å gå tilbake til brukeroversikten i prosjektet eller du kan velge å legge til og lage ny bruker. Når du velger en av disse vil systemet sende en automatisk e-post til brukeren med innloggingsdetaljer. En kopi av denne e-posten vil bli sendt til deg. Modifisere utstyrsrettigheter Om man har benyttet ansvarsgrupper på artikler i prosjektet kan du sette ulik tilgangsnivå per ansvarsgruppe for brukerne i prosjektet. For å gjøre dette klikk på linken «Utstyrsrettigheter» som vist på bildet under; Figur 4: Editere utstyrsrettigheter Dette vil føre deg til en side som gir en oversikt over alle ansvarsgruppene som er definert i prosjektet; 7 ADMINISTRASJONSVEILEDNING Figur 5: Tilgangsnivå per anbudsgruppe Om en brukers tilgang er begrenset til en eller flere anbudsgrupper vil dette også være flagget på hovedvinduet til brukeren; Figur 6: Bruker har begrensning på ansvarsgrupper Eksempler Om du ønsker å forhindre at en bruker skal editere artikler innenfor en bestemt ansvarsgruppe men ha full tilgang til resterende ansvarsgrupper kan du gi brukeren 1=Full tilgang til ansvarsgruppen han/hun skal kunne editere. For ansvarsgrupper du vil brukeren il brukeren få lov til å jobbe med utstyr i rom men ikke andre spesifikasjoner eller kjernedata på artiklene. Om du ønsker å forsikre deg om at en bruker kun har skrivetilgang til en spesifikk ansvarsgruppe kan du som overordnet rettighet gi tilgang 3=Lese, men i oversikten over ansvarsgrupper overstyre den spesifikke ansvarsgruppen ved å sette 1=Full. Dette vil bety at brukeren vil få lov til å opprette, endre og slette artikler innenfor denne ansvarsgruppen, i tillegg til å legge artikkelen inn i Utstyr i rom. Brukeren vil ikke få lov til å gjøre operasjoner i en utstyrsliste som vil påvirke artikler knyttet til ansvarsgrupper brukeren ikke har tilgang til. F.eks. vil brukeren ikke kunne gi et rom standard utstyrsliste eller slette en utstyrsliste som 8 ADMINISTRASJONSVEILEDNING inneholder artikler i andre ansvarsgrupper. Fordi denne begrensingen er «streng» vil den vanligvis benyttes i kombinasjon med flere utstyrslister (se kapittelet for flere utstyrslister). Om du ønsker at en bruke kun skal kunne se utstyr i en spesifikk ansvarsgruppe kan man gi tilgangsnivå «4=Ingen tilgang» som en standardinnstilling på utstyr, men overstyre og sette 1-3 på ansvarsgruppen(e) brukeren skal kunne se/editere. Dette vil medføre at brukeren ikke vil se artikler brukeren ikke har tilgang til verken i artikkelregisteret eller i Utstyr i rom. Dette vil inkludere artikler der ansvarsgruppe ikke er satt. Om du ønsker å skjule en ansvarsgruppe for en bruker kan du enten benytte deg av eksempelt i forrige avsnitt eller sette 1,2 eller 3 som standard og overstyre den spesifikke ansvarsgruppen ved å sette 4. Potensielle problemer med utstyrsrettigheter I noen av eksemplene over kan du i tillegg til å gi begrensede rettigheter på enkelte ansvarsgrupper, fjerne tilgang totalt ved å gi nivå 4. Dette kan føre til noe forvirring blant brukerne om brukeren f.eks. har «1=Full» tilgang på utstyr men ikke kan se artikler innenfor en spesifikk ansvarsgruppe. Dette vil medføre at brukeren heller ikke vil kunne knytte et rom til standard utstyrsliste eller slette utstyrslisten fordi den inneholder utstyr brukeren ikke har tilgang til. Så om man velger å skjule artikler for en bruker er det anbefalt at disse artiklene legges i en egen utstyrsliste. Om en bruker har lesetilgang til noen artikler og skrivetilgang til andre kan det være forvirrende om det leggs til tilleggsartikler knyttet til andre ansvarsgrupper. F.eks. om du ikke har tilgang til ansvarsgruppe IT, men full tilgang til ARK og artikkelen du skal fjerne fra et rom er knyttet til IT vil du ikke kunne fjerne denne tillegsartikkelen selv om hovedartikkelen er knyttet til ARK. Dette fordi ved å fjerne tilleggsartikkelen vil du påvirke antallet av en artikkel du ikke har tilgang til. Begrense skriverettigheter til en fane i artikkelspesifikasjon Du kan begrense en brukers skrivetilgang til kun å gjelder en eller flere faner i artikkelspesifikasjonen. Klikk på «Artikkelspesifikasjon» i detaljvinduet for brukertilgang. Merk at om du gir en bruker 1=Full på utstyr og begrenser brukeren på en fane i artikkelspesifikasjonen vil brukerens tilgang begrenses slik at han/hun ikke vil ha mulighet for å endre artiklenes kjerneinformasjon (numre, navn, pris etc.) 9 ADMINISTRASJONSVEILEDNING Figur 7: Begrense skrivetilgang til en fane i artikkelspesifikasjon 2.3. Databaseadministrator Som databaseadministrator har du de samme mulighetene som en prosjektadministrator, i tillegg kan du opprette/slette prosjekter og databaser, endre navn på databaser og endre epost maler. Et eksempel på velkomstmenyen ser du på bilde under. 10 ADMINISTRASJONSVEILEDNING Figur 8: Hovedmeny databaseadministrator Nytt prosjekt/database Nytt prosjekt opprettes fra Prosjekter Nytt prosjekt. Når du oppretter ett nytt prosjekt vil du få valget om du vil opprette en ny database for prosjektet eller om du vil legge prosjektet under en eksisterende database. En database kan ha flere prosjekter og kan utveksle data mellom disse. I tillegg er flere data felles for alle prosjektene innenfor en database. En database kan også tenkes på som en byggherre, der noe er felles for alle prosjektene til byggherren og noe er prosjektspesifikt. Denne figuren illustrerer hva som ligger i de forskjellige delene og som er nærmere beskrevet nedenfor. 11 ADMINISTRASJONSVEILEDNING En database inneholder data som er felles for alle prosjektene innenfor databasen. Om du gjør endringer i data i databasen medfører det endringer i alle prosjektene i følgene områder: Et felles planartikkelregister, med tilhørende artikkelspesifikasjoner og tilleggsartikler Skjemaoppsett for spesifisering av artikler En felles standardromliste med tilhørende standard RFP og utstyrslister Skjemaoppsett for RFP slik at RFP kan kopieres og samme RFP kan kopieres og brukes i alle prosjektene En rekke innstillinger som er ansett for å være de samme for flere prosjekt hos en byggherre, slik som: Brukergruppetyper, arealtyper, romnavn og hovedromtyper, ansvarsgrupper mm. Disse fellesdataene muliggjør gjenbruk av data for flere lignende prosjekter. I tilfeller der dette ikke passer må man opprette en ny database De viktigste prosjektspesifikke data er: Romfunksjonsstrukturen Romliste med tilhørende informasjon om RFP og utstyrslister for rommene Logoer og prosjektnavn Om du velger å opprette en ny database må du gi denne et navn. Det blir dette navnet som skal inn i feltet for Database i innloggingsvinduet i dRofus. Det kan derfor være greit å velge et kort og enkelt navn. Det er kun lov med bokstaver (a-z), tall (1-9), bindestrek (-) og underscore (_) i databasenavnet. Første tegn i navnet må også være en bokstav. Du må også velge en mal den nye databasen skal være basert på. Mer om hva som følger med fra databasen du velger som mal kan du lese om over. I neste steg fyller du inn prosjektnavn, byggherre og evt. beskrivelse og brutto areal. Om alt er fylt ut riktig har du nå opprettet et nytt prosjekt og du kan gå i gang med å opprette brukere. 12 ADMINISTRASJONSVEILEDNING Endre og kopiere database Som databaseadministrator har du også mulighet til å gå inn og endre navn på eksisterende databaser. Klikk på Database fra startmenyen og du kan se er slikt symbol til høyre for hver database. Viktig: Når du endrer navn på en database endrer du også navnet som skal tastes inn i feltet for Database i innloggingsvinduet i dRofus. Alle brukere i det aktuelle prosjektet må derfor få beskjed om denne endringen. Endre derfor aldri navnet på en database om det ikke er absolutt nødvendig. Når du klikker deg inn på en database fra databaseoversikten kan du lage en kopi av valgt navn på databasen. 2.4. Brukeradministrasjon Som databaseadministrator har man mulighet for å se hvilke brukere som er pålogget og å kaste ut brukere som er pålogget, om man f.eks. ønsker å kopiere eller lage en ny database basert på en eksisterende database. Inaktive brukere Denne listen viser brukere som ikke har vært aktive i en lengre periode. Man kan sette filter på 6 måneder, ett år, to år eller aldri logget inn ved å benytte «Sist innlogget filteret» i toppmenyen. Koble fra bruker Man har mulighet for å koble en bruker fra en database som brukeren er logget inn i. Dett gjøres ved å gå inn i listen «Tjenerstatus» som gir en oversikt over alle som er pålogget dine prosjekter. Her har man et rødt kryss til høyre for hver bruker som kaster brukeren ut av pålogget database. 2.5. Forbedringer i brukerdetaljer Om man går inn på en brukers detaljer har man tre nye valg i dRofus 16 -> i forhold til eldre versjoner; 13 ADMINISTRASJONSVEILEDNING Se brukerlogg Her kan man se en detaljert logg over når brukeren har logget seg inn og hvilken versjon av dRofus som er benyttet. Endre passord Det er nå mulig å endre en brukers passord fra administrasjonssystemet. En databaseadministrator kan endre en brukers passord, men kun midlertidig, brukeren må endre passordet når han/hun logger seg inn i dRofus til et personlig passord slik at sikkerheten er ivaretatt. Deaktiver bruker Ved å klikke på «Deaktiver bruker» valget kan en databaseadministrator deaktivere brukeren for all brukertilgang på serveren. Brukerens brukernavn vil stå i grått i prosjektenes brukerlister med et valg om å re-aktivere brukeren. 14 ADMINISTRASJONSVEILEDNING 3. INNSTILLINGER Som administrator kan du endre innstillinger som påvirker ulike deler av programmet. Dette gjøres via valget AdministrasjonInnstillinger; Følgende vindu vil åpnes: Før man gjør endinger i innstillinger må man være klar over at enkelte endringer vil endre måten dRofus oppfører seg når den generer forskjellig data. Hvis du f.eks. går til RomInnstillinger og endrer «Antall romnivå i romfunksjonssnummer» så vil dette endre hvordan dRofus genererer romfunksjonssnumre. Alle valg i innstillingene er forklart ved å flytte musemarkøren over de blå spørsmålstegnene. 15 ADMINISTRASJONSVEILEDNING Noen endringer krever at vinduer i dRofus må oppdateres. Dette fører til at dRofus vil lukke alle åpne vinder etter at endringer i «Innstillinger» er gjort. 16 ADMINISTRASJONSVEILEDNING 4. TIDA Dette kapittelet forklarer de ulike tilpassninger/justeringer som kan gjøres i TIDA for oppsett av databasen som administrator. NB: Når du gjør endringer forklart i dette kapittelet må du ofte lukke og åpne TIDA vinduet for at du skal se endringen. Noen generelle endringer må du også lukke programmet og starte på nytt for å se endringer. 4.1. TFM nummer og andre kjernedatavalg Et TFM nummer består av +A=B.C-DET der A er lokasjonskoder, B er systemgruppe, C er systemløpenr, D er komponenttype (klassifikasjon) og E er komponentløpenr og evt T hvis typeunikt. -) kan ikke endres på uten videre. ABC gjelder for systemer, mens DE og T gjelder for komponenter (komponenter arver ABC biten fra systemet de ligger i). I de påfølgende avsnittende vil jeg forklare hvordan de kan tilpasses i TIDA. Lokaliseringskode De lokaliseringskoder som ønskers benyttet i et prosjekt må settes av en med administrasjonsrettigheter. Man kan endre dem under menyvalget: AdministrasjonHovedprosjekt/prosjektTIDALokalisering Systemgrupper Systemgrupper kan legges til/endres eller slettes ved å høyreklikke i treet i TIDA på en systemgruppe hvis en har TIDA rettighet = 1 (full). Dette registeret kommer normalt ferdig satt opp i henhold til TFM kodingen i prosjekter. MERK: Hvis du legger til nye systemgrupper må du huske på å også lage knytning til det filter med de felter du ønsker skal vises (hvis noen). Se avsnitt 0 Komponenttype Normalt ved oppstart så ligger de komponenttyper som er definert i TFM standarden ferdig lastet, men ønsker man å endre på disse kan man gjøre det under menyvalget: AdministrasjonHovedprosjekt/prosjektTIDAKomponent type. MERK: Hvis du legger til nye typer må du huske på å også lage knytning til det filter med de felter du ønsker skal vises. Se avsnitt 0 Typeunik Normalt i prosjekter ønsker man å benytte konseptet med typeunik. Man må markere et komponent nummeret sitt. Denne oppførselen kan deaktiveres i databasen. Se avsnitt 4.5. 17 ADMINISTRASJONSVEILEDNING Validering og lengde på komponent og system løpenr Både systemløpenr og komponentløpenr blir validert i databasen ved oppdateringer. Den vanlige reglen her er at begge kun må bestå av tall og være 3 tegn lange. Dette kan i midlertid overskrives hvis prosjektet f.eks. ønsker at det skal være 4 tegn i komponentløpenr i stedet for. Man kan også lage seg løpenr på system skal være 3, men for alle som ligger under gruppen 43 Høyspenning skal det være 4 tegn i nummeret. Dette må du kontakte Nosyko for å få endret, men er en enkel operasjon ved oppstart. Statusvalg Både systemer og komponenter kan gis en status. Dette kan f.eks. benyttes for å ha ulik oppfølging og eller søk. De ulike valgene settes i menyvalget: AdministrasjonHovedprosjekt/prosjektTIDAStatusvalg Kontrakt Både systemer og komponenter kan gis en kontrakt. De ulike kontraktene defineres i AdministrasjonHovedprosjekt/prosjektTIDAKontrakt. Når nye brukere defineres i prosjektet kan de bli begrenset til en eller flere kontrakter. Det betyr at brukeren kun kan endre på de systemer/komponenter som er kodet med en av de kontraktene hun er medlem av. Dette registeret brukes også av mangelsystemet for å kunne fordele byggmangler til riktig kontrakt/entreprise. Ansvar Komponenter og systemer kan også tildeles et ansvar. Dette kan benyttes for å f.eks. fordele arbeid og/eller for å søke opp. Dette registeret er det samme ansvarsvalgene som benytte for artikler i dRofus og kan endres i: AdministrasjonHovedprosjekt/prosjektUtstyrAnsvarsgrupper. Dette feltet kan defineres at ikke skal benyttes i databasen (fjernes). Se avsnitt 4.5. Rollenavn / Tilkobling Når en oppretter en relasjon mellom systemer og eller komponenter må man gi den relasjonen en tilkobling hvis man har TIDA rettighet 1. Andre brukere må kun velge fra den forhåndsdefinerte listen. De ulike valgene kan endres i: AdministrasjonHovedprosjekt/prosjektTIDARolle 4.2. Komponentforslag Når man oppretter nye komponenter i TIDA under et system får man opp en dialog med forslag til komponenter som ofte benyttes under det systemet. Både hvilken komponenttype, men også navneforslag. Listen over det som benyttes her kan sees under: AdministrasjonHovedprosjekt/prosjektTIDAKomponent forslag Merk at her så refereres det ti systemgrupper: AdministrasjonHovedprosjekt/prosjektTIDAsystemgrupper, men skal det gjøres en større oppdatering er det best om du kontakter Nosyko så kan de bistå. 18 ADMINISTRASJONSVEILEDNING 4.3. Velge hvilke tekniske data felter som skal vises (filter) Introduksjon I TIDA er det mulig å definere hvilke felter som skal vises for ulike typer data. For eksempel er det ikke sikkert at man ønsker et like omfattende skjema med samme felter for et vindu som for et aggregat. Dette er løst i tida ved at man har noe vi kaller visningsfilter og typefilter. Et filter, eller visning, er egentlig bare en gruppering av ulike felter fra tekniske data (se avsnitt 4.4 for hvordan endre eller legge til felter). Typefilter Typefilter er de filter som kan knyttes om mot komponenter og systemer som er ulikt klassifisert (f.eks. hvilke felter skal vises for et veggsystem kontra et luftbehandlingssystem). Dette gjør en ved at en knytter systemklassifikasjonen (systemgruppen) til et filter. Alle system som ligger i den systemgruppen vil da kun vise de feltene som er i filteret. Merk at en systemgruppe kan dermed bare ha ett filter, men det samme filteret kan brukes av flere systemgrupper. Akkurat samme prinsippet gjelder for komponenttyper eller produkttyper. Dermed kan ulike komponenter i samme system ha forskjellig visning i tekniske data (systemfilteret har ingen ting å si for komponenten og omvendt). Prinnsipp bak typefilter 1) Alle felter i teknisk data: 2) Et filter bestemmer en eller flere felter I tekniske data. Flere filter kan peke på same felt. Materiale Overflatebehandling Farge Brannklasse Filter 1 Filter 2 Filter 3 3) En systemgruppe kan knyttes til et filter. Da vil kun feltene i filteret vises for systemer i gruppen. 240 overflate gulv 242 overflate vegg 249 spesialsystem 263 overlys 4) En komponentklassifikasjon kan knyttes til et filter. Da vil kun feltene i filteret vises for komponenter av den typen uavhengig av hvilket system den er i. AB Bjelke AG Glassfelt AS Søyle BI Islolasjon 1) For å legge til nye felter må du se avsnitt 7.4. 2) Nye filter kan du lage ved å gå til menyvalget: AdministrasjonTIDA typefilter 19 ADMINISTRASJONSVEILEDNING Klikk på ny og dobbeltklikk eller bruk pilknappene for å legge til eller fjerne felter fra filteret. Når du klikker lagre har du laget et nytt filter med de valte feltene på høyre side. Merk at et felt kan være med i flere filter. 3) For å knytte en eller flere systemer til et typefilter gå til: AdministrasjonHovedprosjekt/prosjektTIDAsystemgrupper. Ved å legge navnet til typefilteret inn til systemgruppen får den denne visningen. Merk at du kan la flere systemgrupper benytte seg av samme typefilter. 4) For å knytte en eller flere komponenttyper til et typefilter gå til: AdministrasjonHovedprosjekt/prosjektTIDAKomponent type. Også her kan du da legge en referanse til et visningsfilter. Også her kan du la flere komponenttyper til samme typefilter. Visningsfilter Visningsfilter virker på mange måter tilsvarende som typefilter. Teknikken bak fungerer på samme måte at man lager en relasjon mellom ett eller flere felter og et filter. Men et visningsfilter knyttes ikke til noen klassifikasjon. Visningsfilter er noe brukeren selv kan velge og er laget for at brukeren selv kan få se noen av de tekniske data i listen og skjule de felter som ikke er en del av visningsfilteret. Les mer om bruk av visningsfilter i brukermanualen for TIDA. For å endre/lage visningsfilter gå til Administrasjon TIDA visningsfilter. Selve filteret lages akkurat tilsvarende som typefilter. 4.4. Endringer i skjermbilder Mye av de skjema som en kan fylle ut i TIDA kan, som andre moduler i dRofus, tilpasses den enkelte database. Dette er noe vi kaller dynamisk GUI (Graphical user interface). definere flere dynamiske faner som skal vises på komponent, system eller begge. Når det gjelder selve utformingen av felter (legge til nye, endre navn osv) gjøres det under menyvalget AdministrasjonDynamisk GUITeknisk informasjonsdatabase. Les i kapittel 5 for generell forklaring av dette. MERK: Hvis du legger til nye felter må du huske på å også legge det inn i de filtre du ønsker at det skal vises. Se avsnitt visningsfilter over. 20 ADMINISTRASJONSVEILEDNING Velge hvilke faner som skal vises hvor Når man definerer felter i dynamisk GUI så legges de inn i flere grupperinger. Den øverste (groveste) inndelingen er det vi kaller faner. Normalt legges alle faner som defineres for TIDA som undergrupper under teknisk spesifikasjon, men man kan også definere at de skal vises som egne faner på systemer/komponenter i stedet for. Disse endringene kan man gjøre i AdministrasjonHovedprosjekt/prosjektTIDATIDA faner De valg man kan fylle ut i plassering er der en av følgende verdier: spec Fanen vises som en del av tekniske data comp_and_sys Fanen vises både for systemer og komponenter component Fanen vises bare for komponenter system Fanen vises bare for systemer system/komponent. Skjermbildene nedenfor viser eksempel på at en har valgt å vise en fane utenfor tekniske data: komponenter: 4.5. Globale databasevariable Har du administrasjonsrettigheter i et prosjekt kan du sette disse ved å gå til menyvalget i dRofus: AdministrasjonHovedprosjekt/prosjektinnstillinger: 21 ADMINISTRASJONSVEILEDNING 3 1 2 1) Hvis tida-disable-typeunique er satt til 1 betyr det at man ikke benytter typeunik i prosjektet. Dvs valget finnes ikke der og man kan sette et antall på alle komponenter. De vil heller ikke få T bak seg i nummeret. 2) Hvis tida-disable-responsibility er satt til 1 vil ansvar feltet ikke vises hverken for komponenter eller systemer. 3) Hvis tida-enable-tiandv ikke er satt til 1 vil man ikke få mulighet til å knytte til produsent/leverandør. Man kan heller ikke legge opp dokumenter eller åpne firmaregister eller vedlikeholdsregister. 22 ADMINISTRASJONSVEILEDNING 5. DYNAMISK SKJEMAER (GUI) I dRofus kan flere skjermbilder selv defineres av prosjektet. Disse skjermbildene kan redigeres av en med administratortilgang til prosjektet. For tiden kan følgende skjemaer endres: 5.1. RFP Funksjonsprogram Rombehandling Artikkelspesifikasjon Faner under innkjøp (anbudsgruppe, anbud, tilbud, avtale, bestilling, mottak) TIDA system og komponent. Oppbygning av faner, grupper og felter Dynamisk GUI er gruppert i 4 nivåer: Faner, grupper, elementer og felt. Et felt kan være ja/nei felt, tekstfelt, numerisk felt osv. Det er i disse man kan skrive inn verdier som blir lagret til databasen. En kan også legge t Et element er ett eller flere felter på en linje og en ledetekst. For eksempel kan et element bestå av t tekstfelt for eventuelle kommentarer. En gruppe består av flere elementer, gruppert sammen i visning og rapporter f.eks. med en ledetekst og en ramme. En fane er en eller flere grupper. Disse vises som en fane i skjema og gruppert sammen i rapporter. Figuren nedenfor viser en elementer (markert i blått i den første gruppen) og felter (markert i grønt i det første elementet). 5.2. Endring av skjema For å endre på disse skjemaene gå til menyen Administrasjon->Dynamisk GUI-> og velg det skjema du vil endre. Merk at du må trykke på for å være sikker på at lagringen fungerer. for å lagre endringene dine permanent. Gjør dette ofte 23 ADMINISTRASJONSVEILEDNING MERK: Funksjonaliteten i denne delen av programmet er ikke like gjennomtestet som de delene som er beregnet for vanlige brukere. Vi anbefaler deg derfor å lagre ofte. Hvis noe skulle få galt under lagring, avslutt dRofus og start på nytt (det holder ikke å bare lukke editoren). Da vil data fra databasen leses inn på nytt. l høyre øverst vises egenskaper til den fanen/gruppen/elementet/feltet du har valgt i treet. Under vises en Legge til eller endre faner Fo Følgende egenskaper er knyttet til faner: Felt Forklaring Posisjon Hvilken innbyrdes posisjon denne fanen har i forhold til de andre fanene Navn Teksten som skal vises på fanen og i rapporten XSL rapportmal Velger hvilket utseende gruppen skal ha i PDF rapporter. Dette styres hovedsakelig på gruppe, se under, men hvis man har en to kolonnes fane kan du -columnl komme ut slik de gjør på skjermen. Ved bruk av to kolonner på gruppen under vil de ulike feltene komme gruppevis fra venstre mot høyre og ned. Dette kan gi en litt annen rekkefølge enn på skjermen. Legge til eller endre gruppe Velg fanen du vil legge gruppen til og velg Ny. Følgende egenskaper er knyttet til grupper: 24 ADMINISTRASJONSVEILEDNING Felt Forklaring Navn Teksten som skal vises på fanen og i rapporten Hjelpetekst IKKE I BRUK Posisjon rad Horisontal (rad) posisjon i forhold til de andre gruppene Posisjon kolonne Vertikal (kolonne) posisjon i forhold til de andre gruppene Kant rundt Vise en ramme rund gruppen med navnet på gruppen øverst. XSL rapportmal Velger hvilket utseende gruppen skal ha i PDF rapporter. Se under. MERK: Gruppene tegnes per kolonne. Dette betyr at først tegnes f.eks. alle gruppene i kolonne 1 før en begynner å tegne grupper i kolonne 2. Gruppene i kolonne 2 er alle justert slik at de ikke begynner før etter den gruppen i kolonne 1 som var bredest (slik som tabellen over). Hvordan PDF rapporten skal se ut styres gjennom valget XSL rapportmal. Her har du følgende muligheter: Type group Forklaring Standard gruppe med ledetekst til element og så feltverdier for hvert felt på en linje. Hvis feltene har navn som er markert at skal vises foran/bak feltet vil også dette komme frem. Ulike type felter (tekst, tall, logisk) har ulike faste bredder. document-group gruppeoverskrifter og elementoverksifter kommer som nummererte headinger og innhold formateres som i et dokument. description-group Brukes på grupper som består av kun et stort flerlinjers tekstfelt. Her vil navnet på gruppen komme i bold over teksten i feltene. two-column Elementene kommer i to kolonner. tree-column Elementene kommer i tre kolonner. Typisk passende for elementer der det er kun ett felt dyn-field-table Lager en tabell av feltene i elementene i denne gruppen. Elementer er rader og felter er kolonner. Må kun brukes på grupper der alle elementer har like mange felter. Den vil benytte første element for å utlede antall kolonner i tabellen og eventuelle overskrifter på kolonnene ved å se på feltnavnene. Alle etterfølgende elementer må være like! Den vil fordele plassene jevnt mellom feltene. value-spec er flere enn to felter i elementet vil de vises fortløpende etter det andre feltet. value-spec-no-header Samme som over men uten overskrift for bruk på flere etterfølgende grupper av samme type. value-spec-two-column Samme som value-spec men i to kolonner value-spec-two-columnno-header Samme som over men uten overskrift. yes-no-spec-min-max percent area Mal tilpasset rombehandling %, m2 percent-area-no-header Samme som over men uten overskrifter for bruk for flere etterfølgende grupper av samme type percent-meter-no-color % m kolonne oppsett for rombehandling. Legge til eller endre element Velg gruppen du vil legge element til og velg Ny. Du kan også velge en av de predefinerte element/felt fra høyreklikkmenyen: Ja/Nei kommentar felt. Lager et element med et logisk felt og et tekst felt. Ja/Nei antall kommentar felt. Lager et element med et logisk, numerisk og et tekstfelt Ja/Nei % m2 felt. Lager et element med et logisk og to numeriske felter beregnet på rombehandlingsskjema. 25 ADMINISTRASJONSVEILEDNING Fordelen med å bruke en av de predefinerte malene er at blant annet at alle feltinnstillinger, slik som at feltene blir tilgjengelige når det logiske feltet hakes av, er gjort. Følgende egenskaper Felt Forklaring Posisjon Hvilken innbyrdes posisjon dette elementet har i forhold til de andre elementene i gruppen Navn Teksten som skal brukes foran elementet, altså ledeteksten til feltene Hjelpetekst Hjelpetekst til feltet. Dette vil i RFP bildet komme til syne nederst i skjembildet når brukeren fyller ut feltet. XSL rapportmal IKKE I BRUK Du kan flytte elementer rekkefølgen på denne måten (posisjon) Legge til eller endre felter Velg gruppen du vil legge til et felt til og velg Ny. Felter kan være av forskjellige typer og har også litt forskjellige valg avhengig av type. Følgende typer er tilgjengelig: Felttype Forklaring Flerlinjers tekstfelt Tekstfelt for tekst som kan gå over flere linjer. Man kan selv angi størrelsen på feltet Knapp Felt som tekstfelt og to knapper for å gjøre valg. Brukes kun i rapportvinduet. Logisk felt Ja/Nei felt (checkbox) Numerisk felt Felt for tallverdier. Man kan angi lovlig størrelse og presisjon (antall desimaler) Radioknapper/Combobox Felt der man kan velge mellom flere forhåndsdefinerte valg (tekster). Kan presenteres som en nedtrekksmeny(combobox) eller radioknapper Tekstfelt Standard felt for tekst på en linje. Tid dato velger Felt for valg av dato og tid Uediterbar tekst Felt for fast tekst som ikke kan endres. Vises heller ikke i rapporter. Kan brukes til f.eks. å lage overskrifter. Alle feltene har følgende egenskaper: Felt Forklaring Felttype En av typene som beskrevet over. Posisjon Innbyrdes posisjon på feltet innenfor elementet Navn Et eventuelt navn på feltet (i tillegg til ledeteksten i elementet) For at det skal vises må man angi dette i neste valg. Vis navn Hvor navnet skal vises (foran eller bak feltet) Dette vises ikke i rapporter. Her må man velge en passende XSL mal for å få frem meningen med feltet. Hjelpetekst Teksten som vises i en gul boks når man holder musepekeren over feltet. Bruk primært elementet sin ledetekst (se forrige avsnitt), for å angi felles tekst for alle felter innenfor et element. Angi hjelpetekst her kun hvis det er ytterligere spesifisering. Kun avlesning Valg for om feltet eventuelt ikke skal være mulig å endre Aktiveres/deaktiveres av Hvilket logisk felt som eventuelt styrer om dette feltet aktiveres/deaktiveres. På denne måten må f.eks. det logiske feltet krysses av før man skriver tekst i et annet felt i samme element. Kalkuler felt Brukes kun i rombehandling. Angir hvilket felt som skal kalkuleres når dette feltet endres. Dette brukes kun av rombehandlingsskjema. Kalkuleringsfunksjon Hvilken funksjon skal brukes til å kalkulere feltet som er valgt over. IfcPropertySet Navnet på det PropertySet (PSet_XXX) som dette feltet skal eksporteres i under IFC eksport (synkronisering i modell). Hvis dette feltet er blankt vil navnet på fanen bli brukt, hvis dette ikke skal skrives til objektet (se under) IfcProperty Navnet på Property som dette feltet skal eksporteres som under PropertySet som valgt over. Hvis dette feltet er blank og IfcPropertySet (over) også er blankt, benyttes navnet på elementet. Hvis dette feltet ikke er blankt men IfcPropertySet er blank, vil eksportrutinen forsøke å eksportere direkte til en 26 ADMINISTRASJONSVEILEDNING egenskap på objektet. F.eks. hvis du ønsker å sette verdi fra RFP til IfcSpace.Description, setter du dette feltet til Description, men lar IfcPropertySet (over) være blankt. IFD GUID 2 En Global Unik ID (GUID) som identifiserer feltet unikt. Dette kan være ID hentet fra IFD . Du kan Denne ID brukes når data eksporteres/importeres via IFC for å identifisere like felter/informasjon i ulike databaser. Hvis feltet ikke har noen ID kan kan ikke kopiere f.eks. RFP mellom felter. Bredde/Høyde Bredde og høyde på feltet. Disse feltene behøver ikke fylles ut for de fleste felter, da de vil få standard størrelser. For flerlinjertekstfelt må det oppgis. Størrelsen oppgis i piksler med unntak av flerlinjertekstfelt der man kan velge dette (se under) OwnerAlignment Angir hvordan feltet skal oppføre seg når man endrer størrelsen på vinduet. Brukes kun i spesielle tilfeller. Følgende egenskaper gjelder kun for angitt felttype: Felttype Flerlinjers tekstfelt Knapp Felt Forklaring Vis navn (labell) over Angir om navnet på elementet (ledeteksten) skal vises over feltet istedenfor at ledeteksten vises på siden og feltet etter. Stil utseende Angir hvordan størrelse (bredde/høyde) er angitt. Størrelse på feltet. Dette kan angis som antall pixler bred, antall elementer høy eller % bred, % høy der % er et tall fra 1-100 som angir hvor stor del i prosent feltet skal dekke av tilgjengelig plass i vinduet. Knapp tekst BRUKES IKKE Sym navn Navn på metoden i vinduet som skal kalles når man trykker på knappen Type Knappstil Logisk felt Understrek Angir om ledeteksten skal være understreket. Numerisk felt Format Angir formatet på det numeriske feltet. Dette kan angis på to måter: - {antall tegn ink to desimaler og komma} - {antall tegn ink desimaler og komma, antall desimaler} Dette betyr at både {5} og {5,2} gir det samme, nemlig XX,YY. {6,3} vil gi deg XX,YYY, mens kun heltall opp til 9999 kan angis som {4,0}. Radioknapp/Combobox Stil/utseende Angir hvordan flervalgsfeltet skal vises - Combobox uediterbar, gir en nedtrekksmeny der som ikke kan editeres direkte, men man må velge ett av valgene. - Combobox, editerbar, gir en nedtrekksmeny med mulighet til å skrive fritt eller velge ett av valgene menyen. - Gruppe uten ramme, label på siden. Gir radioknapper plasser under hverandre per valg med ledeteksten på venstre side - Horisontale radiobokse uten ramme. Gir radioknapper plasser etter hverandre horisontalt og ikke under hverandre som over. - Standard design, gruppe med ramme. Gir radioknappene plasser under hverandre med en ramme rundt og ledeteksten i rammen. Elementer Her angis valgene som brukeren kan velge mellom. Ett per linje. Fjern valg knapp I tilfelle en av radioknapp typene vises en knapp som man kan bruke til å nullstille alle valg, altså fjerne valget sitt med. I tilfelle combobox legges det inn et blankt valg i nedtrekksmenyen, med mindre den er editerbar, da man kan fjerne valget ved å fjerne teksten selv. Knapp tekst tekst for knappen. Hvis ingen ting blir skrevet her brukes teksten 2 Tid/dato velger Antall dager tilbake som standard Hvor mange dater tilbake fra dagens dato som skal være forhåndsvalgt. Uediterbar tekst Sentrer teksten IKKE BRUK Understrek Om teksten skal være understreket eller ikke Tekstverdi Teksten som skal vises International Framework for Dictionaries 27 ADMINISTRASJONSVEILEDNING Lagring og forhåndsvisning Verdier du skriver inn i egenskapene lagres automatisk lokalt når du skifter gruppe/felt/fane/element. Alle som logger seg på etter du har gjort dette vil da se endringene dine. lokalt, men ikke nødvendigvis til databasen for at du skal se endringene. Sletting av felter, elementer, grupper og faner Lagre til databasen med en gang du har slettet noe og for hvert ting du sletter. I mange tilfeller må loggen for det aktuelle skjema stanses før du kan slette felter. Dette gjøres under Administrasjon>Hovedprosjekt/prosjekt->Hovedprosjekt->Logger. Hvis du får feil under sletting er det mest sannsynelig dette som er årsaken. ADVARSEL!: Sletting av felt fører til at alle data som er lagret på feltet blir slette. All logg om feltet blir også borte. 5.3. Funksjonsprogram I funksjonsprogrammet fungerer dynamisk GUI stort sett på samme måte som for de andre. Det er noen unntak når det gjelder bl.a. visning og legg til filter som figurene under viser: Flagg navn Element navn Felt 5.4. RFP visningsfilter Visninger begrenser hvilke felter som er synelig i RFP skjema. Det finnes to typer visninger: 28 ADMINISTRASJONSVEILEDNING Systemvisning: Dette er visninger som defineres av en med administrasjonstilgang til prosjektet og som ikke brukere ellers kan se. Vi kan bruke slike visninger til å angi hvilke felter man ønsker å benytte i prosjektet til enhver tid. RFP skjena kan inneholde en mengde felter som ikke er aktuelle å bruke i et konkret prosjekt eller man ønsker å begrense til noen få felter i en periode av prosjektet. Man kan definere så mange systemvisninger man ønsker, men bare en er synelig for brukerne og det er den som er definert som prosjektet standardvisning. Standardvisingen er den som brukerne vil få opp når de åpner RFP bilde, eksporter til Excel og skriver ut. Brukervisning: Visninger merket som brukervisninger kan alle brukere benytte. Her kan man f.eks. definere visinger etter hva slags felter enkelte brukere skal fylle ut eller visninger som kan brukes på visse typer rom. Definering og endring av visninger Visninger kan opprettes, slettes og endres fra menyen Administrasjon->RFP visingsfilter. For å opprette en visning, trykk på Ny. Gi visningen et navn og velg om dette skal være en brukervisning eller ikke. Hvis du ikke angir brukervisning, blir dette en systemvisning. Du kan også angi om visningen skal være standard eller ikke. Du kan nå velge hvilke felter som skal være med i visningen ved å flytte felter fra venstre (tilgjengelige felter) til høre (felter som er med i visningen). Dette gjøres ved å merke feltet du vil ha med og bruke knappene i midten av vinduet eller dobbeltklikke på dem. 29 ADMINISTRASJONSVEILEDNING 6. TEKNISK ARKITEKTUR OG INSTALLASJON AV DROFUS TJENER 6.1. Innledning dRofus bygger på en klient/tjener arkitektur. Programmet er sammensatt av fire sentrale komponenter: En sentral databasetjener En sentral rapport-/dokumenttjener Windows klientprogram Et sentralt administrasjonssystem Databasetjener, administrasjonssystem og rapport-/dokumenttjeneren kan installeres på samme eller ulike fysiske maskiner. Når man bruker programmet må man være tilkoblet databasetjeneren. Databasen kan enten stå hos Nosyko AS eller installeres hos oppdragsgiver. Dette er en fordel for eksempel hvis en stor prosjektgruppe jobber daglig med programmet. Nosyko AS må ha tilgang til tjeneren utenfra for å kunne drifte og vedlikeholde den. For at klientprogramvaren skal kunne kommunisere med tjeneren åpen med følgende porter: TCP port 5432 for kommunikasjon mot databasetjeneren TCP port 8180 for kommunikasjon mot rapport-/dokumenttjener Disse portene må selvfølgelig være åpne inn til tjeneren hvis prosjektet har denne stående hos seg. I dette tilfelle må også følgende porter kunne åpnes: 6.2. TCP port 22 for at Nosyko AS skal kunne administrere tjeneren via SSH3. Denne kan åpnes TCP port 80 for at man skal kunne benytte administrasjonssystemet, som er web applikasjon. Dette kan åpnes mot de nett der slik administrasjon er nødvendig. Databasetjener Alle data ligger på en sentral tjener. Endringer gjort av en bruker blir dermed straks synlig for andre brukere. Dette gjør også at man unngår konflikter ved samtidige oppdateringer på f. eks samme rom. All flerbruksproblematikk blir tatt hånd om av databasen. Databassystemet som benyttes av dRofus er PostgreSQL 8.3, som er fritt nedlastbar4. Dette er åpen kildekode programvare som har en fri lisens slik at programvaren fritt kan installeres og brukes uten ekstra lisenskostnader. Nosyko AS benytter Linux i sine installasjoner siden *nix plattformene er langt mer uttestet med denne databasen enn Windows. Databasen installeres på vanlig måte i henhold til 5 installasjonsinstruksene , eller normalt sett som binærpakken i den distribusjonen som benyttes. For optimal resultat bør databasen settes opp med verdier tilpasset maskinvaren den er installert på6. Databasen må videre være tilgjengelig fra Internett og akseptere koblinger på port 5432 (standard) med 7 8 MD5 autentifisering . Trafikken mot databasetjeneren kan settes opp til å gå over SSL hvis ønskelig. 3 Secure Shell http://www.postgresql.org 5 http://www.postgresql.org/docs/8.1/interactive/installation.html 6 http://www.postgresql.org/docs/8.1/interactive/runtime-config-resource.html 7 http://www.postgresql.org/docs/8.1/interactive/client-authentication.html#AUTH-PG-HBA-CONF 8 Secure Socket Layer 4 30 ADMINISTRASJONSVEILEDNING Man kan deretter laste inn databaseskjema for dRofus (gjøres av Nosyko AS) eller gjenopprette en backup.. Databasen er avhengig av en tilleggsfunksjon for global ID generering. Denne må lastes ned, kompileres og installeres først9. Denne er foreløpig kun tilgjengelig for *nix plattformen. 6.3. Rapport-/dokumenttjener Rapporttjener genererer rapporter sentralt etter forespørsler fra klientprogrammet. Dette skjer på en tjener fordi det er tidvis svært maskinkrevende, og dessuten muliggjør det utrulling av nye rapporter uten oppdatering i klientprogramvaren. Den håndterer også overføring og lagring av dokumenter hvis man ønsker å benytte dokumenthåndteringssystemet i drofus. Tjeneren vil i de fleste tilfeller ligge på samme maskin som databasetjeneren, men kan også plasseres på en annen maskin hvis ønskelig. Rapporttjeneren er et java program som generer XML data fra drofus databasen. Dette blir videre transformert med XSL-FO10 til PDF. Rapport-/dokumenttjenere er basert på Java og trenger følgende Sun Java 1.5 eller høyere11 12 Apache Tomcat Java Servlet Container 5.0 eller høyere. 13 Apache Axis2 Apache FOP14 0.95 (distribuert med rapportapplikasjonene) Rapporttjeneren distribueres som en servlet. Last ned Tomcat og installer den som angitt på denne siden. Rapportserveren distribures som en WAR fil som installeres som forklart i dokumentasjonen til tomcat. Rapportserveren er deretter klar for bruk. Dokumenthåndteringsystemet er en web service (AAR fil) som installeres under Axis. 6.4. Klientprogram Klientprogrammet er Windows-programmet drofus. Klientprogrammet er grensesnittet mot brukerne som de benytter for å endre data og generere rapporter. Programmet kan kjøres på alle nye Windows maskiner. Det er lagt stor vekt på enkel navigering og gjennomgående enkelt og forståelig oppbygning, slik at man med litt kjennskap i bruk av Windows-programmer enkelt kan bruke programmet. Klientprogrammet er felles for alle installasjoner av drofus. Før man kan bruke programmet må man logge seg på den sentrale databasen. All brukertilgang styres gjennom denne og programmet er derfor fritt tilgjengelig for nedlastning fra våre websider. Klientprogramvaren er utviklet med utviklingsverktøyet Visual Objects15/Vulcan.NET16 og kan kjøre på alle Windows 32-bit plattformer (Windows 9x/ME/2000/XP/Vista). Det anbefales og bruke Windows 2000/XP/Vista. For systemkrav se dokumentet Introduksjon til dRofus. Klientprogrammet distribueres som en eksekverbar installasjonsfil (IKKE .msi). og klientprogrammet må installeres på hver enkelt PC. Installasjonen krever i utgangspunktet ikke administrasjonstilgang til maskinen, og kan installeres på et område der brukeren selv har skrivetilgang. Hvis en ønsker å installere programmet for brukerne sentralt, kan man kjøre installasjonsprogrammet med opsjonen Programmet har også funksjonalitet for å laste ned nye versjoner av programmet og installere disse automatisk. Dette foregår over port 80. Dette vil kreve at bruken selv har tilgang til å installere 9 http://www.hclausen.net/psql-guid.tgz http://www.w3.org/TR/2006/REC-xsl11-20061205/ http://java.sun.com 12 http://tomcat.apache.org/ 13 http://ws.apache.org/axis2/ 14 http://xmlgraphics.apache.org/fop/ 15 http://www.cavo.com 16 http://www.govulcan.net 10 11 31 ADMINISTRASJONSVEILEDNING programmet på sin PC enten ved at man har administrasjonsrettigheter eller at det ligger på et område der man har skrivetilgang. Alternativt må man også ved jevne mellomrom sende ut oppdateringer sentralt. Hvis dere ønsker å bli varslet om viktige oppdateringer så ta kontakt. Oppdateringer kan enkelte ganger være svært viktige. 6.5. Admininstrasjonssystem Administrasjonssystemet er en WEB applikasjon. Denne krever Ruby og RubyOnRails (versjon 2.1), Apache og Passenger (eller en annen web tjener) 6.6. Administrasjon av tjener Nosyko AS benytter Debian Linux i alle installasjoner og anbefaler derfor dette hvis Nosyko skal bistå med oppsett og drift av tjeneren. Nosyko AS må ha tilgang til tjeneren for å utføre nødvendig oppdatering av programvare og database. Vi benytter SSH for kommunikasjon med tjeneren. Denne kan settes opp en offentlig/privat nøkkelautentisering og med tilgang kun fra Nosyko AS sitt nettverk. Backup Backup av databasen kan tas med verktøyet pg_dump som følger med databasesystemet. Fra kommandolinje på serveren kan en backup tas slik: pg_dumpall –u <username> > backup.sql For en komprimert backup, pipe det gjennom gzip: pg_dumpall –u <username> | gzip > backup.sql.gz For å gjenopprette en backup, sørg for å ha tilgang til den nye databasen (vanligvis ved å logge på ed komprimering:) gunzip backup.sql.gz | psql template1 Uten komprimering: psql template1 < backup.sql Nosyko AS har allerede installert rutiner som gjør at backup tas ved ukentlig rotasjon og arkivering. 32
© Copyright 2024