ADMINISTRASJONS- VEILEDNING

Transkript

1 Nosyko AS Rådhusgt. 17 Telefon: Oslo Telefaks: Epost: Web: BRUKERVEILEDNING Versjon ADMINISTRASJONS- VEILEDNING Versjon: 1.7 DOKUMENTDATO:

2 Nosyko AS Rådhusgata Oslo Epost: Web: Telefon:

3 Innhold 1. Innledning Om dette dokumentet Administrasjonssystemet på web Generelt Prosjektadministrator Databaseadministrator Brukeradministrasjon Forbedringer i brukerdetaljer Innstillinger TIDA TFM nummer og andre kjernedatavalg Komponentforslag Velge hvilke tekniske data felter som skal vises (filter) Endringer i skjermbilder Globale databasevariable Dynamisk skjemaer (GUI) Oppbygning av faner, grupper og felter Endring av skjema Funksjonsprogram RFP visningsfilter Teknisk arkitektur og installasjon av drofus tjener Innledning Databasetjener Rapport-/dokumenttjener Klientprogram Admininstrasjonssystem Administrasjon av tjener

4 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. Det forusettes at man kjenner godt til drofus og innholdet av brukerveiledningen 1 før man begynner å bruke administrasjonsfunksjonaliteten. Hvis du mangler et av disse dokumentene, vennligst last ned fra 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 3

5 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 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

6 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, e- post 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

7 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

8 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

9 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

10 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

11 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 e- post maler. Et eksempel på velkomstmenyen ser du på bilde under. 10

12 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

13 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

14 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 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 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

15 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

16 3. INNSTILLINGER Som administrator kan du endre innstillinger som påvirker ulike deler av programmet. Dette gjøres via valget Administrasjon Innstillinger; 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 Rom Innstillinger 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

17 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

18 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 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: Administrasjon Hovedprosjekt/prosjekt TIDA Lokalisering 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: Administrasjon Hovedprosjekt/prosjekt TIDA Komponent 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

19 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: Administrasjon Hovedprosjekt/prosjekt TIDA Statusvalg Kontrakt Både systemer og komponenter kan gis en kontrakt. De ulike kontraktene defineres i Administrasjon Hovedprosjekt/prosjekt TIDA Kontrakt. 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: Administrasjon Hovedprosjekt/prosjekt Utstyr Ansvarsgrupper. 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: Administrasjon Hovedprosjekt/prosjekt TIDA Rolle 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: Administrasjon Hovedprosjekt/prosjekt TIDA Komponent forslag Merk at her så refereres det ti systemgrupper: Administrasjon Hovedprosjekt/prosjekt TIDA systemgrupper, men skal det gjøres en større oppdatering er det best om du kontakter Nosyko så kan de bistå. 18

20 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. 3) En systemgruppe kan knyttes til et filter. Da vil kun feltene i filteret vises for systemer i gruppen. Materiale Overflatebehandling Farge Brannklasse Filter 1 Filter 2 Filter 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 ) Nye filter kan du lage ved å gå til menyvalget: Administrasjon TIDA typefilter 19

21 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: Administrasjon Hovedprosjekt/prosjekt TIDA systemgrupper. 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: Administrasjon Hovedprosjekt/prosjekt TIDA Komponent 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 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 Administrasjon Dynamisk GUI Teknisk 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

22 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 Administrasjon Hovedprosjekt/prosjekt TIDA TIDA faner De valg man kan fylle ut i plassering er der en av følgende verdier: spec comp_and_sys component system Fanen vises som en del av tekniske data Fanen vises både for systemer og komponenter Fanen vises bare for komponenter 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: Administrasjon Hovedprosjekt/prosjekt innstillinger: 21

23 ) 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

24 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: 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) 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

25 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 Posisjon Navn XSL rapportmal Forklaring Hvilken innbyrdes posisjon denne fanen har i forhold til de andre fanene Teksten som skal vises på fanen og i rapporten 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 -column- l 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

26 Felt Navn Hjelpetekst Posisjon rad Posisjon kolonne Kant rundt XSL rapportmal Forklaring Teksten som skal vises på fanen og i rapporten IKKE I BRUK Horisontal (rad) posisjon i forhold til de andre gruppene Vertikal (kolonne) posisjon i forhold til de andre gruppene Vise en ramme rund gruppen med navnet på gruppen øverst. 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: group Type document-group description-group two-column tree-column dyn-field-table value-spec value-spec-no-header value-spec-two-column value-spec-two-columnno-header yes-no-spec-min-max percent area percent-area-no-header percent-meter-no-color 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. gruppeoverskrifter og elementoverksifter kommer som nummererte headinger og innhold formateres som i et dokument. Brukes på grupper som består av kun et stort flerlinjers tekstfelt. Her vil navnet på gruppen komme i bold over teksten i feltene. Elementene kommer i to kolonner. Elementene kommer i tre kolonner. Typisk passende for elementer der det er kun ett felt 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. er flere enn to felter i elementet vil de vises fortløpende etter det andre feltet. Samme som over men uten overskrift for bruk på flere etterfølgende grupper av samme type. Samme som value-spec men i to kolonner Samme som over men uten overskrift. Mal tilpasset rombehandling %, m2 Samme som over men uten overskrifter for bruk for flere etterfølgende grupper av samme type % 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

27 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 Posisjon Navn Felt Hjelpetekst XSL rapportmal Forklaring Hvilken innbyrdes posisjon dette elementet har i forhold til de andre elementene i gruppen Teksten som skal brukes foran elementet, altså ledeteksten til feltene Hjelpetekst til feltet. Dette vil i RFP bildet komme til syne nederst i skjembildet når brukeren fyller ut feltet. 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 Flerlinjers tekstfelt Knapp Logisk felt Numerisk felt Radioknapper/Combobox Tekstfelt Tid dato velger Uediterbar tekst Forklaring Tekstfelt for tekst som kan gå over flere linjer. Man kan selv angi størrelsen på feltet Felt som tekstfelt og to knapper for å gjøre valg. Brukes kun i rapportvinduet. Ja/Nei felt (checkbox) Felt for tallverdier. Man kan angi lovlig størrelse og presisjon (antall desimaler) Felt der man kan velge mellom flere forhåndsdefinerte valg (tekster). Kan presenteres som en nedtrekksmeny(combobox) eller radioknapper Standard felt for tekst på en linje. Felt for valg av dato og tid 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: Felttype Posisjon Navn Vis navn Hjelpetekst Felt Kun avlesning Aktiveres/deaktiveres av Kalkuler felt Kalkuleringsfunksjon IfcPropertySet IfcProperty En av typene som beskrevet over. Innbyrdes posisjon på feltet innenfor elementet Forklaring Et eventuelt navn på feltet (i tillegg til ledeteksten i elementet) For at det skal vises må man angi dette i neste valg. 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. 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. Valg for om feltet eventuelt ikke skal være mulig å endre 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. Brukes kun i rombehandling. Angir hvilket felt som skal kalkuleres når dette feltet endres. Dette brukes kun av rombehandlingsskjema. Hvilken funksjon skal brukes til å kalkulere feltet som er valgt over. 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) 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

28 IFD GUID 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. En Global Unik ID (GUID) som identifiserer feltet unikt. Dette kan være ID hentet fra IFD 2. Du kan Bredde/Høyde OwnerAlignment 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 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) 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 Felt Forklaring Flerlinjers tekstfelt 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 Knapp Knapp tekst BRUKES IKKE Sym navn Type 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 som angir hvor stor del i prosent feltet skal dekke av tilgjengelig plass i vinduet. Navn på metoden i vinduet som skal kalles når man trykker på knappen 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 Tid/dato velger Elementer Fjern valg knapp Knapp tekst Antall dager tilbake som standard Uediterbar tekst Sentrer teksten IKKE BRUK Understrek Tekstverdi - 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. Her angis valgene som brukeren kan velge mellom. Ett per linje. 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. tekst for knappen. Hvis ingen ting blir skrevet her brukes teksten Hvor mange dater tilbake fra dagens dato som skal være forhåndsvalgt. Om teksten skal være understreket eller ikke Teksten som skal vises 2 International Framework for Dictionaries 27

29 Lagring og forhåndsvisning Verdier du skriver inn i egenskapene lagres automatisk lokalt når du skifter gruppe/felt/fane/element. dette vil da se endringene dine. Alle som logger seg på etter du har gjort 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 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

30 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

31 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: TCP port 22 for at Nosyko AS skal kunne administrere tjeneren via SSH 3. 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 nedlastbar 4. 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 installasjonsinstruksene 5, 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 MD5 autentifisering 7. Trafikken mot databasetjeneren kan settes opp til å gå over SSL 8 hvis ønskelig. 3 Secure Shell Secure Socket Layer 30

32 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ørst 9. Denne er foreløpig kun tilgjengelig for *nix plattformen 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-FO 10 til PDF. Rapport-/dokumenttjenere er basert på Java og trenger følgende Sun Java 1.5 eller høyere 11 Apache Tomcat Java Servlet Container eller høyere. Apache Axis2 13 Apache FOP (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 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 Objects 15 /Vulcan.NET 16 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

33 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 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:) Uten komprimering: gunzip backup.sql.gz psql template1 psql template1 < backup.sql Nosyko AS har allerede installert rutiner som gjør at backup tas ved ukentlig rotasjon og arkivering. 32