Hoe de sync werkt

Zodra een project gekoppeld is, is er niets meer te doen: de sync draait automatisch en de twee zijden volgen elkaar. Deze pagina legt uit wat er gekopieerd wordt, wanneer, en wat er gebeurt wanneer beide zijden veranderen.

Wanneer een sync draait

Trigger	Wat er gebeurt
het schema (elke 15 minuten standaard, per project in Instellingen)	het project wordt gelezen en zijn wijzigingen worden weggeschreven
Sync nu op de rij of pagina van het project	hetzelfde, onmiddellijk; de rij toont een spinner en een toast rapporteert het resultaat
een GitLab-webhook	alleen wanneer een webhook geïnstalleerd kon worden voor het token: een wijziging in GitLab triggert een run binnen enkele seconden (het bliksemsymbool op de rij van het project)

Een run leest in pagina's (100 issues per keer) en gaat verder waar hij stopte, dus een grote eerste run neemt meerdere beurten in beslag. Terwijl één run van een project bezig is, wacht een ander verzoek voor hetzelfde project gewoon.

Wat er gekopieerd wordt

Tijdslages → concept-urenlijnen

Elke tijdslage op een issue, een merge request of het project zelf (binnen de labelfilter en het syncvenster) wordt samengevat per persoon, per issue en per dag:

• er wordt één regel aangemaakt of bijgewerkt in Exact als een Concept, op het gekoppelde project, de administratie en het uurtypes uit de koppeling;
• de dag wordt geteld in de tijdzone van de koppeling, dus een log om 01:00 uur op een vlucht vanuit Tokio belandt op de juiste dag;
• negatieve entries (een correctie in GitLab) netten uit tegen dezelfde persoon/issue/dag; wanneer het totaal naar nul of beneden daalt, wordt de regel weer verwijderd, maar alleen zolang deze nog een Concept is;
• een regel die in Exact verwijderd is, wordt nooit opnieuw aangemaakt;
• de eerste run pakt alles vanaf Sync tijdsgelogd vanaf; elke latere run dekt de laatste 45 dagen, zodat oude correcties nog steeds binnenkomen.

De regels zijn met opzet concepten: de persoon die de uren boekt in Exact kan ze nog aanpassen, en niets wordt ingediend of gepost door de sync.

Issues → WBS

Wanneer Issues naar WBS aan staat:

• elke issue binnen het bereik wordt een WBS-activiteit op het gekoppelde Exact-project (milestones worden deliverables, issues hun kinderen, met Milestones);
• de WBS-structuur wordt aangemaakt vanuit GitLab; WBS-regels worden nooit verwijderd in Exact, omdat er uren op geboekt kunnen worden, verwijder ze daar wanneer een project afgerond is;
• een issue die hernoemd is in GitLab hernoemt zijn WBS-regel bij de volgende run.

Exact → GitLab: de statuslabels

Wanneer back-sync aan staat en het token schrijven kan:

Staat van de regels in Exact	Label op de GitLab-issue
enige regel geweigerd	exact::rejected, plus een interne notitie op de issue met de reden
elke regel definitief (goedgekeurd)	exact::approved
anders (concept of ingediend)	exact::submitted

Het label wordt vervangen, niet gestapeld: een issue die exact::submitted was, wordt exact::approved wanneer alle uren definitief zijn. Met een alleen-lezen token wordt deze stap overgeslagen.

Personen

GitLab-gebruikers worden per GitLab-verbinding en per administratie gekoppeld aan Exact-medewerkers:

• een GitLab-gebruiker wiens openbare e-mailadres gelijk is aan het bedrijfs-e-mailadres van een medewerker, wordt automatisch gekoppeld;
• iedereen anders verschijnt onder Personen als on gekoppeld tot er een medewerker gekozen wordt; terwijl ongekoppeld, worden de uren van de gebruiker overgeslagen (ze worden niet op iemand anders geboekt, en gaan niet verloren: ze worden opgepakt zodra de gebruiker gekoppeld is);
• Negeren sluit een gebruiker expres uit (een bot-account bijvoorbeeld).

Personen

Wat	Waar
de lijst	Personen, één rij per GitLab-gebruiker, gegroepeerd per administratie wanneer er meer dan één is
zoeken en alleen ongekoppeld	boven de lijst; alleen ongekoppeld staat standaard aan zolang er ongekoppelde gebruikers zijn
een voorgestelde medewerker	een GitLab-naam/e-mail dicht bij een Exact-medewerker wordt aangeboden als Voorgesteld; Accepteren bevestigt het, Alles accepteren suggesties doet dit voor iedereen
kiezen	de selectie per rij slaat direct op (een vinkje en een toast); Negeren sluit de gebruiker uit
vanuit een run	een runsamenvatting die ongekoppelde gebruikers vermeldt linkt rechtstreeks naar Personen gefilterd op hen

Conflicten

De sync schrijft alleen urenlijnen terwijl ze Concept (of Geweigerd) zijn. Wanneer GitLab zegt dat een regel moet veranderen maar Exact heeft hem al Goedgekeurd (of de regel is daar veranderd op een manier die de sync niet mag aanraken), is het verschil een conflict:

• de run stopt bij de regel en registreert het verschil (wat GitLab heeft, wat Exact heeft, en waarom het niet weggeschreven kan worden);
• de statusbadge van het project toont Conflicten n, en de Overview-pagina telt ze;
• op de projectpagina lijst het tabblad Conflicten elk conflict in woorden op, bijv. Goedgekeurd in Exact, kan niet gewijzigd worden: GitLab heeft 8,0 u op 12 okt, Exact heeft 6,0 u;
• los het op in Exact (wijzig of verwijder de goedgekeurde regel, of pas de tijdslage in GitLab aan): de volgende run leest beide zijden opnieuw en het conflict lost op wanneer ze weer overeenstemmen.

De sync overschrijft nooit stilzwijgend een goedgekeurde regel, en boekt nooit een uur dat een persoon verwijderd heeft.

Wat er niet gesynchroniseerd wordt

• tijdslages buiten het syncvenster op de eerste run (ouder dan Sync tijdsgelogd vanaf);
• uren van on gekoppelde GitLab-gebruikers (overgeslagen, en vermeld onder Personen);
• alles in Exact behalve de tijdlijnen en WBS van het gekoppelde project (geen posten, geen factureren, geen projecten aangemaakt buiten de wizard);
• issues buiten de labelfilter, en gesloten issues op de eerste run (issues die later sluiten worden nog steeds bijgewerkt zolang het project gekoppeld is).