Hvem som kan godkjenne, og hvordan portalen vet det

Fem brytere på hver inngang

En portalinngang har fem boolske verdier: visning, kommentar, godkjenning, opplasting og nedlasting. Studioet angir disse når det oppretter inngangen, og en inngang som forespørres uten rettigheter, blir kun for visning. Hver portalrute deklarerer den ene rettigheten den trenger, og en wrapper sjekker inngangen før ruten kjører, slik at en rute aldri trenger å huske å sjekke selv.

Godkjenning er bryteren som gjelder for signering. Beslutningsruten krever den; en inngang som kun har visning eller kommentar kan ikke nå ruten i det hele tatt, og svaret blir den samme avvisningen som en fremmed får. Portalsiden leser inngangens rettigheter når den åpnes, og skjuler det inngangen ikke kan gjøre, slik at en kunde med en inngang som kun tillater kommentarer, ser tråden og ingen godkjenningsknapp, i stedet for en knapp som feiler.

Visning er bevisst ikke underforstått av de andre. En inngang som kan godkjenne, men ikke vise, er en feil et studio kan gjøre via API-et, og produktet lar visningsruten avvise dette slik at studioet oppdager det, i stedet for å reparere det i det stille.

En prosjektinngang eller en kundeinngang

En inngang peker på ett prosjekt eller på én kunde. En prosjektinngang ser det prosjektet og ingenting annet. En kundeinngang ser alle prosjektene til den kunden. En inngang som ikke peker på noen av delene, ser ingenting, og kan derfor ikke beslutte noe. Om en gitt godkjenning er opp til denne inngangen å avgjøre, besvares av den samme regelen lest baklengs: godkjenningen ligger på en oppgave, oppgaven på et prosjekt, og inngangen må være begrenset til det prosjektet eller til det prosjektets kunde.

Prosjektet og kunden en inngang peker på, sjekkes mot studioets egen organisasjon før inngangen opprettes, slik at en inngang aldri kan peke på tvers av organisasjoner, og et manglende prosjekt eller en manglende kunde gir svaret «ikke funnet» i stedet for å opprette en inngang med en løs referanse.

Påminnelsesjobben bruker den samme begrensningsregelen til å bestemme hvilke innganger som skal puffes når en godkjenning overskrider sin SLA, slik at inngangen som blir påminnet, alltid er en inngang som faktisk kan handle.

Én inngang per person

En inngang har en etikett studioet velger, for eksempel kundens navn, eller én person hos kunden. Når studioet oppretter en inngang for en kunde uten å angi noe mer, går invitasjonen til kundens egen kontakt-e-post og telefon. Når inngangen er for én bestemt person – for eksempel markedssjefen i stedet for fakturaadressen – oppgir studioet denne personens e-post eller telefon, og invitasjonen går dit i stedet.

For en sterkere kobling mellom inngangen og personen, kan en inngang kreve en engangskode på SMS eller e-post i tillegg til lenken: seks sifre, fem minutter, fem forsøk, og mulighet for ny sending etter ett minutt. En inngang kan også begrense antall enheter, fra én til tjue. Med en grense på én vil en ny enhet som logger på, flytte inngangen til seg selv og avslutte alle andre økter umiddelbart; med en høyere grense avsluttes bare den eldste økten. Den samme enheten blir aldri kastet ut: en sideoppdatering eller en tapt informasjonskapsel er ikke en straff.

Studioets historikk viser, per inngang, hvor mange unike enheter som har brukt den. En inngang som er ment for én person, men som viser seks enheter, er en lenke som har blitt videresendt, og studioet kan tilbakekalle den og opprette en ny i løpet av samme minutt.

Når studioet tar beslutninger på vegne av kunden

En produsent kan også registrere en beslutning på studiosiden, med kundens ord i hånd. Beslutningsraden inneholder da produsentens bruker-ID og aktørtypen «user». En beslutning fra portalen har aktørtypen «portal» og ingen bruker-ID. De to kan alltid skilles fra hverandre i strømmen og i revisjonsloggen, slik at «kunden godkjente» og «vi godkjente for kunden» aldri blir samme rad.

Interne signeringer – et godkjenningssteg en produsent eller regissør godkjenner – er den samme mekanismen, med et studiomedlem som godkjenner og de ansvarlige for oppgaven som personene som blir påminnet når det drøyer for lenge.

Utløp, tilbakekalling og hva studioet ser

En inngang utløper som standard etter 30 dager. Studioet kan angi fra 1 til 365 dager, eller eksplisitt velge at den aldri utløper; en utelatt verdi vil aldri la en permanent inngang stå åpen ved et uhell. En tilbakekalt inngang avviser tilgang umiddelbart. En tilbakekalt inngang vises som tilbakekalt i stedet for utløpt i studioets liste, fordi et studio som har deaktivert en lenke, ønsker å se at de har gjort det.

Studiosiden viser alle innganger med etikett, status, rettigheter, når den først ble åpnet, sist sett, unike enheter og antall registrerte kundegodkjenninger. Før denne listen fantes, var det ærlige svaret på «har hun åpnet den?» en telefonsamtale.

Opprettelse og tilbakekalling av en inngang blir loggført, med inngangens innstillinger og aldri påloggingsinformasjonen. Et avvist forsøk på pålogging blir også loggført, med årsaken – ikke funnet, tilbakekalt, utløpt eller engangskode påkrevd – registrert for studioet og aldri vist til personen ved inngangen, ettersom ulike feilmeldinger kan hjelpe noen som prøver å gjette seg frem.

• Standardinngang: kun visning, 30 dager, invitasjon til kundens kontaktrad.
• Godkjenning krever godkjenningsbryteren; brukergrensesnittet skjuler det inngangen ikke kan gjøre.
• Omfanget er ett prosjekt eller én kunde; aldri på tvers av organisasjoner.