For intern systemadministrasjon¶
Som intern systemadministrator hos Konti jobber du på tvers av alle tenants. Du oppretter nye kunder, aktiverer moduler, overvåker drift og håndterer hendelser som påvirker plattformen som helhet.
Tilgang: System-administrasjon krever Konti-intern bruker med tilgang til system-databasen (
wv_sys). Denne rollen er IKKE en tenant-rolle — den eksisterer på tvers av kunder og må behandles deretter.
Dine viktigste oppgaver¶
| Du vil... | Gå til |
|---|---|
| Opprette en ny kunde-tenant | Tenant-provisioning |
| Aktivere eller deaktivere en modul for en kunde | Domain/modul-administrasjon |
| Ta backup eller restore av en tenant | Backup og restore |
| Kjøre/overvåke databasemigrasjoner | Migrasjonsprosess |
| Administrere runtime-konfigurasjon | Runtime-config-admin |
| Sette opp OAuth på systemnivå | OAuth-konfigurasjon system |
| Forvalte KAI master-prompts | KAI master-prompts |
| Håndtere produksjonsincident | Incident response |
| Lese audit-log på tvers av tenants | System audit |
| Behandle bug-rapporter fra kunder | Bug-rapport-håndtering |
System-database vs. klient-database¶
ePortal har to typer database som du må aldri blande:
To databaser per Konti-installasjon¶
| Database | Hva | Repository base-klasse |
|---|---|---|
wv_sys (én per Konti-installasjon) |
Brukerkontoer, domener, modul-registry, OAuth, system-konfigurasjon | BaseSystemRepository |
wv_client_* (én per kunde-tenant) |
All kunde-data: brukere, prosjekt, tid, arbeidsordre, lager, CRM, økonomi | BaseRepository |
Se intern utviklerdokumentasjon (CLAUDE.md "Database table ownership" i kildekoden) for fullstendig oversikt. Tabellnavn som ser like ut hører hjemme i ULIKE databaser:
- wv_UserAccount (system) ≠ wv_User (klient)
- wv_ModuleMenu (system, legacy) ≠ wv_Menu1/2/3 (klient, aktiv)
Multi-tenant-prinsipper du må huske¶
- Tenant-isolasjon er ikke valgfri. Datatilgang-regler, container-prefiksering på blob-storage og connection-string-routing er kritiske. En lekkasje på tvers av tenants er sikkerhets-incident — ikke en bug.
- Plattform-endring påvirker alle. Endringer i
wv_sys, runtime-config, modul-registry treffer hver tenant. Vurder konsekvenser før utrulling. - Versjonering er per kunde. Ulike kunder kan kjøre ulike versjoner samtidig. Sjekk versjon før du svarer på et spørsmål.
- Inscale før vekst. Når en ny kunde provisjoneres, må alle modul-template-rader, menu-template-rader, OAuth-config, DataAccess-default-rows osv. opprettes — uten dette får kunden "tom" tilgang.
Vanlige incident-mønstre¶
| Symptom | Sannsynlige årsaker | Første sjekk |
|---|---|---|
| Én kunde ned, andre kjører | Kunde-spesifikk migrasjon, connection-string, lisens | wv_DomainModule + kunde-database tilkobling |
| Alle kunder ned | System-DB, system-app, infrastruktur | wv_sys tilgjengelighet + Azure-status |
| Sentral integrasjon feiler | Rotert hemmelighet, endret IP-whitelist, oppgradert API | OAuth-konfigurasjon + integrasjonsleverandørens status-side |
| Bakgrunnsjobber feiler i bulk | Schedulering, queue, connection-pool | Job-tabell + Azure Functions-logger |
| Datatilgang fungerer uventet | Manglende seed i wv_DataAccess, ObjectType-fallback til "Own" |
Per CLAUDE.md "New DataAccess ObjectType" |
Hva du IKKE skal gjøre uten å tenke¶
- Aldri kjør destruktive SQL-spørringer direkte i prod. Bruk migrasjonsverktøyet, ikke håndskrevet
DELETE. - Aldri commit hemmeligheter. Repo-wide regel — system-administrasjon er ikke unntak.
- Aldri force-push på sentrale branches. Ikke fra system-rollen din heller.
- Aldri test sikkerhets-hypoteser i prod uten godkjent prosess. Bruk dedikert pen-test-miljø.
Vanlige problemer¶
"En ny tenant har ikke fått standardmenyer"¶
Ved tenant-provisioning kjøres TenantProvisioningService.SeedInitialData() som blant annet seeder wv_Menu1/2/3 fra MenuTemplate-blokken i hver modul. Hvis menyer mangler:
- Sjekk om alle relevante moduler er registrert i
wv_Module - Sjekk om
wv_DomainModulehar riktig modul-aktivering for denne tenanten - Sjekk at hver modul har en
MenuTemplatei sitt*.menu.ts-manifest - Kjør re-seeding hvis det er gjenopprettelig (se Migrations-dokumentasjon)
"DataAccess-regler ekskluderer brukere som tidligere så data"¶
Vanlig årsak: ny ObjectType ble lagt til uten å seede wv_DataAccess-default-rader. Repository fall-back er AccessScope = "Own" per CLAUDE.md regel — det kan kutte tilgang dramatisk. Sjekk om migrasjon for den nye ObjectType inkluderte seed.
"En tenant ser data fra en annen tenant"¶
Stopp arbeidet. Dette er sikkerhetsincident. Følg incident-response-prosessen, ikke prøv å løse i isolasjon.
Trenger du mer hjelp?¶
- For arkitektur-spørsmål: snakk med plattform-eier
- For sikkerhets-incident: følg Konti sin etablerte sikkerhets-prosess (ikke gjennom standard support)
- For migrasjons-spørsmål: sjekk
docs/database_scripts/og relevantMigration_*.cs-fil - For tverr-kunde-statistikk: bruk system-audit-loggen, ikke ad-hoc SQL i prod