BudgetCoach — bestandswerkwijze en rolmodel

Versie: 2.2.0

Vaste werkwijze voor codebestanden

Bij wijzigingen aan BudgetCoach leveren we bestanden zoveel mogelijk volledig en direct vervangbaar aan.

Dat betekent:

• geen losse codeblokken als een volledig bestand redelijkerwijs kan worden aangeleverd;

• correcties worden vooraf al in het volledige bestand verwerkt;

• we voorkomen instructies als "zoek deze functie", "verwijder dit blok" of "plak dit onderaan" wanneer een compleet vervangbestand mogelijk is;

• bij een gewijzigde Code.gs leveren we bij voorkeur de volledige nieuwe Code.gs;

• bij een gewijzigde Scripts.html leveren we bij voorkeur de volledige nieuwe Scripts.html;

• ongewijzigde bestanden hoeven niet opnieuw te worden vervangen, maar we melden expliciet dat ze ongewijzigd kunnen blijven;

• er mag maar één globale BC-configuratie in actieve .gs-bestanden bestaan;

• oude of tijdelijke .gs-bestanden mogen geen dubbele globale functies of configuraties achterlaten;

• HTML/browsercode hoort in .html en Apps Script-servercode in .gs.

Doel: we kunnen een bestand in Apps Script openen, alles selecteren, vervangen door het nieuwe volledige bestand, opslaan en testen zonder handmatig code te moeten samenvoegen.

Rollen

SUPERADMIN

• lezen en schrijven in de eigen gekoppelde administratie;

• gebruikers aanmaken en beheren;

• klantaccounts aan administraties koppelen;

• alle actieve Users-accounts met een ClientSpreadsheetId openen;

• samen met een klant in dezelfde administratie werken;

• toegangsmails sturen;

• coachbeheer en klanttoewijzing beheren.

COACH

• eigen administratie gebruiken wanneer gekoppeld;

• alleen administraties openen van gebruikers waarvoor CoachUserId gelijk is aan het eigen User-ID;

• lezen en schrijven in die toegestane administraties;

• geen gebruikersrollen of globale rechten wijzigen.

KLANT

• alleen de eigen gekoppelde administratie openen;

• lezen en schrijven in de eigen administratie;

• inloggen met wachtwoord of e-mailcode;

• zelf een wachtwoord instellen of resetten;

• geen andere klanten of administraties zien.

ADMIN uit BC_Users

• bestaande centrale OS 2.x beheerfuncties behouden;

• klanten, abonnementen, signalen, acties en coachinformatie beheren volgens de bestaande BC_Users-architectuur.

CUSTOMER uit BC_Users

• bestaande OS 2.x klantflow behouden;

• eigen gekoppelde klantadministratie lezen en schrijven;

• bestaande workbook-create/link/connection-JSON-functies blijven beschikbaar.

Samenwerken in dezelfde administratie

Voor de nieuwe Users-werkruimte is ClientSpreadsheetId de koppeling naar de financiële administratie.

Een aanbevolen klantflow is:

1. SUPERADMIN maakt of kiest de klantadministratie.

2. SUPERADMIN maakt een KLANT-account aan.

3. Bij dat account wordt hetzelfde ClientSpreadsheetId opgeslagen.

4. CoachUserId wordt ingesteld op de verantwoordelijke SUPERADMIN of COACH.

5. De klant ontvangt een toegangsmail.

6. De klant logt thuis of op afstand in via e-mailcode of wachtwoord.

7. SUPERADMIN/COACH opent via Beheer → Open administratie dezelfde klantadministratie.

8. Beide werken dus in dezelfde Google Sheet en zien na vernieuwen elkaars wijzigingen.

Er wordt voor samenwerking geen tweede kopie van dezelfde klantadministratie gebruikt.

Werkcontext

SUPERADMIN en COACH kunnen een toegestane gebruiker als werkcontext openen.

De gewone schermen blijven hetzelfde:

• Overzicht

• Transacties

• Begroting

• Schulden

• Benodigdheden

• Administratie

Alle lees- en schrijfopdrachten worden daarna server-side opnieuw gecontroleerd tegen de gekozen gebruiker en diens ClientSpreadsheetId.

Een KLANT kan niet zelf naar een andere werkcontext schakelen.

Beveiligingsregels

• autorisatie wordt server-side gecontroleerd;

• een browserparameter of User-ID alleen is nooit voldoende voor toegang;

• SUPERADMIN mag alle actieve Users-accounts openen;

• COACH mag alleen zichzelf en toegewezen klanten openen;

• KLANT mag alleen zichzelf openen;

• wachtwoorden worden niet als platte tekst opgeslagen;

• wachtwoordreset verifieert de nieuw opgeslagen hash voordat succes wordt gemeld;

• bestaande sessies worden na een wachtwoordreset ingetrokken;

• toegangsmails bevatten geen wachtwoord;

• klanten kunnen veilig met e-mailcode starten en daarna zelf een wachtwoord instellen.