Compare commits
2 Commits
fix/issue-
...
fix/issue-
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
ed1b1eb80f | ||
|
|
3de5500343 |
@@ -137,9 +137,6 @@ The platform ships a global chatbot avatar called **R42**, rendered as the Respe
|
||||
* **PocketBase auto-cancellation is OFF.** Set in `src/lib/pb.js`; never re-enable.
|
||||
* **Go through `callLLM`.** Never call the Anthropic proxy directly; you lose retry, schema validation, and telemetry.
|
||||
* **AI token budget.** Truncation surfaces as `LLMTruncatedError` (`stop_reason: max_tokens`). For extraction, tighten the prompt's topic cap before raising `max_tokens`.
|
||||
* **PocketBase migrations & the `_migrations` ledger (issue #18).** The deployed Labs/prod databases were originally provisioned WITHOUT `--migrationsDir` (schema came from `scripts/setup-pb-collections.mjs`), so their ledger started empty. `pb_migrations/1000000000_baseline_ledger_sync.js` marks the historical files as applied on such databases — never remove it, never rename an applied migration file (the ledger is filename-based), and give new migrations a timestamp that sorts after the existing ones. A failed migration aborts `pocketbase serve` → container crash-loop → 502 on every `/api/*` call; the deploy playbooks gate on `/api/health` to catch this.
|
||||
* **OIDC provider config lives in a hook, not a migration.** `pb_hooks/entra_oidc.pb.js` reconciles the Entra provider from `ENTRA_*` env on every bootstrap + cron tick. Don't move provider credentials back into a one-shot migration — an apply while the env is empty would permanently disable OAuth2.
|
||||
* **JSVM hook scope.** PocketBase runs each hook callback as an isolated program: top-level functions in a `*.pb.js` file are NOT in scope inside callbacks. Shared helpers live in `pb_hooks/utils.js` and are pulled in per-callback via `require(`${__hooks}/utils.js`)`.
|
||||
|
||||
## 13. 26-Week Per-User Curriculum System
|
||||
The platform uses a **26-week perpetual curriculum cycle**. Every employee covers the knowledge base in focused, thematic weekly blocks, **starting whenever they enroll**.
|
||||
|
||||
10
Caddyfile
10
Caddyfile
@@ -46,16 +46,6 @@
|
||||
}
|
||||
|
||||
handle_errors {
|
||||
# Don't mask API errors with the SPA shell — return a proper
|
||||
# JSON error so the frontend can display a meaningful message.
|
||||
# NOTE: `respond` only accepts `body`/`close` subdirectives; the
|
||||
# Content-Type must be set via a separate `header` directive. An
|
||||
# invalid subdirective is a Caddyfile parse error and crash-loops
|
||||
# the container at startup (issue #20).
|
||||
@api path /api/*
|
||||
header @api Content-Type application/json
|
||||
respond @api `{"code":{err.status_code},"message":"Backend unavailable"}` {err.status_code}
|
||||
|
||||
rewrite * /index.html
|
||||
file_server
|
||||
}
|
||||
|
||||
@@ -12,13 +12,7 @@ services:
|
||||
container_name: pocketbase-learning
|
||||
restart: unless-stopped
|
||||
working_dir: /pb
|
||||
env_file:
|
||||
# Optional: absent .env.local must not block `docker compose up` (issue #18).
|
||||
- path: .env.local
|
||||
required: false
|
||||
command: ["serve", "--http=0.0.0.0:8090", "--dir=/pb/pb_data", "--migrationsDir=/pb/pb_migrations"]
|
||||
ports:
|
||||
- "8090:8090"
|
||||
volumes:
|
||||
- pb_data:/pb/pb_data
|
||||
- ./pb_migrations:/pb/pb_migrations
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
# Authentication — Azure (Entra ID) login
|
||||
|
||||
> Implemented for issue #16. Replaces the previous client-side PIN login.
|
||||
> Hardened for issue #18 (migratie-ledger-sync + env-onafhankelijke provider-reconciliatie).
|
||||
|
||||
## Doel
|
||||
|
||||
@@ -41,22 +40,13 @@ Browser (SPA) PocketBase (auth) Entra ID
|
||||
| 003 | Provisioning + admin-rol via `pb_hooks/team_members.pb.js` | Rol-logica server-side, niet in de client |
|
||||
| 004 | Admin-rol via e-mail-allowlist (`ENTRA_ADMIN_EMAILS`), re-synced elke login | Geen handmatig beheer; allowlist-wijziging werkt bij volgende login |
|
||||
| 005 | API-rules → `@request.auth.id != ""` op alle app-collecties | Geen anonieme toegang meer; admins/users zijn beide geauthenticeerd |
|
||||
| 006 | Baseline-ledger-sync migratie voor out-of-band geprovisionede DB's | Labs/prod draaide historisch zonder `--migrationsDir`; replay van de historie crashte PB (issue #18). De vroegst-sorterende migratie markeert de historie als applied wanneer schema bestaat maar de ledger leeg is |
|
||||
| 007 | Migratie = structuur, hook = configuratie | De OIDC-provider wordt bij elke start (en per cron-minuut) gereconcilieerd vanuit `ENTRA_*` env door `pb_hooks/entra_oidc.pb.js`; een one-shot migratie die van deploy-time env afhangt kan OAuth2 anders permanent uitschakelen |
|
||||
| 008 | Hook-helpers via `require(`${__hooks}/utils.js`)` | De JSVM draait elke hook-callback als geïsoleerd programma; top-level functies zijn níet in scope op call-time |
|
||||
| 009 | `createRule: '@request.context = "oauth2"'` op `team_members` | PocketBase past de createRule toe op de OAuth2-sign-up (eerste login maakt het record aan); `null` blokkeerde élke eerste login met 403 (issue #22). De context-rule staat alléén de OAuth2-flow toe — anonieme REST-creates blijven geweigerd |
|
||||
| 010 | Claims uit het Entra **id_token** (`userInfoURL: ""`) + UPN-fallback voor e-mail | Graph `/oidc/userinfo` geeft géén `email`-claim voor accounts zonder mail-attribuut → 400 bij eerste login (issue #24). Het id_token bevat altijd `preferred_username` (UPN = primair e-mailadres bij Respellion); `entra_oidc.pb.js` gebruikt die als fallback (regex-guard tegen guest-UPN's) en logt gefaalde OAuth2-pogingen naar de containerlog |
|
||||
|
||||
## Bestanden
|
||||
|
||||
| Bestand | Rol |
|
||||
|---|---|
|
||||
| `pb_migrations/1000000000_baseline_ledger_sync.js` | Detecteert een out-of-band geprovisionede DB (schema bestaat, `_migrations`-ledger leeg) en markeert de historische migraties als applied, zodat de replay niet crasht (issue #18). |
|
||||
| `pb_migrations/1781000000_team_members_to_auth.js` | Converteert relation-velden naar text (data blijft behouden), dropt de oude PIN-collection en maakt `team_members` als auth-collection. Idempotent; provider wordt alleen als fast-path meegenomen als de env al aanwezig is. |
|
||||
| `pb_migrations/1781000000_team_members_to_auth.js` | Dropt de oude PIN-collection, maakt `team_members` als auth-collection met de OIDC-provider (creds uit env). |
|
||||
| `pb_migrations/1781000001_tighten_api_rules.js` | Zet alle niet-systeem-collecties op `@request.auth.id != ""`. |
|
||||
| `pb_migrations/1781000002_allow_oauth2_signup.js` | Zet `createRule = '@request.context = "oauth2"'` op reeds-gemigreerde omgevingen (issue #22). |
|
||||
| `pb_hooks/entra_oidc.pb.js` | Reconcilieert de OIDC-provider vanuit `ENTRA_*` env bij elke start + cron-tick (compare-before-save). |
|
||||
| `pb_hooks/utils.js` | Gedeelde helpers (`resolveRole`, `reconcileEntraOidc`) — per callback binnenhalen via `require()`. |
|
||||
| `pb_hooks/team_members.pb.js` | Auto-provisioning (`role`, `enrollment_status`, naam-fallback) + admin-rol re-sync. |
|
||||
| `src/lib/azureAuth.js` | Canonieke, unit-geteste helpers (`OIDC_PROVIDER`, `resolveRole`, `parseAdminEmails`, `deriveName`). |
|
||||
| `src/store/AppContext.jsx` | `loginWithAzure()` / `logout()` op basis van `pb.authStore` + `authRefresh()`. |
|
||||
@@ -110,11 +100,6 @@ Ansible-variabelen (vault): `entra_tenant_id`, `entra_client_id`,
|
||||
eerste deploy.
|
||||
- Verweesde voortgangsrecords van verwijderde (pre-Azure) users zijn acceptabel:
|
||||
zonder geldig Entra-account kan niemand inloggen, dus die records zijn onbereikbaar.
|
||||
- Credential-rotatie: update de `ENTRA_*` secrets (Gitea → Ansible `.env`) en
|
||||
herstart/redeploy — `pb_hooks/entra_oidc.pb.js` reconcilieert de provider
|
||||
automatisch bij elke start en elke cron-minuut. Geen handmatige re-apply meer.
|
||||
- **Migratiebestanden nooit hernoemen nadat ze ergens applied zijn** — de
|
||||
`_migrations`-ledger is filename-based; hernoemen triggert een re-apply.
|
||||
- De deploy-playbooks bevatten een health-gate: als PocketBase na de deploy niet
|
||||
healthy wordt, faalt de pipeline zichtbaar en print hij de containerlogs
|
||||
(issue #18 bleef 2 weken onzichtbaar doordat de deploy "groen" was).
|
||||
- Credential-rotatie: update env + herconfigureer de provider via de PocketBase
|
||||
admin-UI (Settings → Auth providers) of ship een follow-up migratie — de
|
||||
create-migratie draait maar één keer.
|
||||
|
||||
@@ -72,81 +72,3 @@
|
||||
state: present
|
||||
files: compose.yml
|
||||
recreate: always
|
||||
|
||||
# A failed migration aborts `pocketbase serve` and the container crash-loops
|
||||
# while `docker compose up` still reports success (issue #18). Gate the
|
||||
# deploy on PocketBase actually serving its health endpoint.
|
||||
- name: Wait for PocketBase to become healthy
|
||||
ansible.builtin.command: docker exec pocketbase-learning wget -q -O - http://127.0.0.1:8090/api/health
|
||||
register: pb_health
|
||||
until: pb_health.rc == 0
|
||||
retries: 18
|
||||
delay: 5
|
||||
changed_when: false
|
||||
ignore_errors: yes
|
||||
|
||||
- name: Collect PocketBase logs for diagnosis
|
||||
ansible.builtin.command: docker logs --tail 80 pocketbase-learning
|
||||
register: pb_logs
|
||||
when: pb_health is failed
|
||||
changed_when: false
|
||||
failed_when: false
|
||||
|
||||
- name: Abort deploy — PocketBase is not healthy
|
||||
ansible.builtin.fail:
|
||||
msg: |
|
||||
PocketBase did not become healthy after the deploy (health endpoint unreachable).
|
||||
Recent container logs:
|
||||
{{ pb_logs.stdout | default('') }}
|
||||
{{ pb_logs.stderr | default('') }}
|
||||
when: pb_health is failed
|
||||
|
||||
# The frontend container carries the SPA + Caddy. An invalid Caddyfile
|
||||
# crash-loops it at startup while the PocketBase gate stays green — that
|
||||
# outage (issue #20) was invisible to CI because the test job swaps in
|
||||
# Caddyfile.test. Gate on the real container actually serving.
|
||||
- name: Wait for the frontend (Caddy) to become healthy
|
||||
ansible.builtin.command: docker exec learning-platform wget -q --spider http://127.0.0.1:80/
|
||||
register: fe_health
|
||||
until: fe_health.rc == 0
|
||||
retries: 18
|
||||
delay: 5
|
||||
changed_when: false
|
||||
ignore_errors: yes
|
||||
|
||||
- name: Collect frontend logs for diagnosis
|
||||
ansible.builtin.command: docker logs --tail 80 learning-platform
|
||||
register: fe_logs
|
||||
when: fe_health is failed
|
||||
changed_when: false
|
||||
failed_when: false
|
||||
|
||||
- name: Abort deploy — frontend is not healthy
|
||||
ansible.builtin.fail:
|
||||
msg: |
|
||||
The frontend (Caddy) container did not become healthy after the deploy.
|
||||
Recent container logs:
|
||||
{{ fe_logs.stdout | default('') }}
|
||||
{{ fe_logs.stderr | default('') }}
|
||||
when: fe_health is failed
|
||||
|
||||
# Observability behind the auth perimeter: surface the end-to-end state
|
||||
# in the CI log on every deploy.
|
||||
- name: Post-deploy smoke report
|
||||
ansible.builtin.shell: |
|
||||
cd /opt/learning-platform
|
||||
echo '--- docker compose ps ---'
|
||||
docker compose ps
|
||||
echo '--- frontend -> pocketbase proxy health ---'
|
||||
docker exec learning-platform wget -q -O - http://127.0.0.1:80/api/health || echo 'PROXY HEALTH FAILED'
|
||||
echo '--- team_members auth methods (OIDC provider present?) ---'
|
||||
docker exec pocketbase-learning wget -q -O - http://127.0.0.1:8090/api/collections/team_members/auth-methods || echo 'AUTH-METHODS FAILED'
|
||||
echo '--- pocketbase logs (tail 30) ---'
|
||||
docker compose logs --tail=30 pocketbase-learning
|
||||
register: smoke_report
|
||||
changed_when: false
|
||||
failed_when: false
|
||||
|
||||
- name: Show smoke report
|
||||
ansible.builtin.debug:
|
||||
msg: "{{ smoke_report.stdout_lines }}"
|
||||
|
||||
@@ -72,81 +72,3 @@
|
||||
state: present
|
||||
files: compose.yml
|
||||
recreate: always
|
||||
|
||||
# A failed migration aborts `pocketbase serve` and the container crash-loops
|
||||
# while `docker compose up` still reports success (issue #18). Gate the
|
||||
# deploy on PocketBase actually serving its health endpoint.
|
||||
- name: Wait for PocketBase to become healthy
|
||||
ansible.builtin.command: docker exec pocketbase-learning wget -q -O - http://127.0.0.1:8090/api/health
|
||||
register: pb_health
|
||||
until: pb_health.rc == 0
|
||||
retries: 18
|
||||
delay: 5
|
||||
changed_when: false
|
||||
ignore_errors: yes
|
||||
|
||||
- name: Collect PocketBase logs for diagnosis
|
||||
ansible.builtin.command: docker logs --tail 80 pocketbase-learning
|
||||
register: pb_logs
|
||||
when: pb_health is failed
|
||||
changed_when: false
|
||||
failed_when: false
|
||||
|
||||
- name: Abort deploy — PocketBase is not healthy
|
||||
ansible.builtin.fail:
|
||||
msg: |
|
||||
PocketBase did not become healthy after the deploy (health endpoint unreachable).
|
||||
Recent container logs:
|
||||
{{ pb_logs.stdout | default('') }}
|
||||
{{ pb_logs.stderr | default('') }}
|
||||
when: pb_health is failed
|
||||
|
||||
# The frontend container carries the SPA + Caddy. An invalid Caddyfile
|
||||
# crash-loops it at startup while the PocketBase gate stays green — that
|
||||
# outage (issue #20) was invisible to CI because the test job swaps in
|
||||
# Caddyfile.test. Gate on the real container actually serving.
|
||||
- name: Wait for the frontend (Caddy) to become healthy
|
||||
ansible.builtin.command: docker exec learning-platform wget -q --spider http://127.0.0.1:80/
|
||||
register: fe_health
|
||||
until: fe_health.rc == 0
|
||||
retries: 18
|
||||
delay: 5
|
||||
changed_when: false
|
||||
ignore_errors: yes
|
||||
|
||||
- name: Collect frontend logs for diagnosis
|
||||
ansible.builtin.command: docker logs --tail 80 learning-platform
|
||||
register: fe_logs
|
||||
when: fe_health is failed
|
||||
changed_when: false
|
||||
failed_when: false
|
||||
|
||||
- name: Abort deploy — frontend is not healthy
|
||||
ansible.builtin.fail:
|
||||
msg: |
|
||||
The frontend (Caddy) container did not become healthy after the deploy.
|
||||
Recent container logs:
|
||||
{{ fe_logs.stdout | default('') }}
|
||||
{{ fe_logs.stderr | default('') }}
|
||||
when: fe_health is failed
|
||||
|
||||
# Observability behind the auth perimeter: surface the end-to-end state
|
||||
# in the CI log on every deploy.
|
||||
- name: Post-deploy smoke report
|
||||
ansible.builtin.shell: |
|
||||
cd /opt/learning-platform
|
||||
echo '--- docker compose ps ---'
|
||||
docker compose ps
|
||||
echo '--- frontend -> pocketbase proxy health ---'
|
||||
docker exec learning-platform wget -q -O - http://127.0.0.1:80/api/health || echo 'PROXY HEALTH FAILED'
|
||||
echo '--- team_members auth methods (OIDC provider present?) ---'
|
||||
docker exec pocketbase-learning wget -q -O - http://127.0.0.1:8090/api/collections/team_members/auth-methods || echo 'AUTH-METHODS FAILED'
|
||||
echo '--- pocketbase logs (tail 30) ---'
|
||||
docker compose logs --tail=30 pocketbase-learning
|
||||
register: smoke_report
|
||||
changed_when: false
|
||||
failed_when: false
|
||||
|
||||
- name: Show smoke report
|
||||
ansible.builtin.debug:
|
||||
msg: "{{ smoke_report.stdout_lines }}"
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
Diversiteit en Inclusiviteit bij Respellion
|
||||
|
||||
Diversiteit en Inclusie Initiatieven
|
||||
* De spreker is betrokken bij een groep genaamd Diverse Leaders in Tech, die zich richt op het bevorderen van diversiteit en inclusie in de technologie-industrie.
|
||||
* Deze groep heeft een enquête van ongeveer 30 vragen ontwikkeld om te beoordelen hoe bedrijven diversiteit en inclusieproblemen aanpakken.
|
||||
* De enquête behandelt onderwerpen zoals beleid, trainingsprogramma's en andere relevante initiatieven.
|
||||
* De groep werkt momenteel samen met Booking.com om hun aanpak te implementeren.
|
||||
* De spreker is geïnteresseerd in het begrijpen van hoe dergelijke initiatieven effectief kunnen worden opgeschaald en geïmplementeerd in grotere organisaties.
|
||||
* Ze verzamelen informatie en ervaringen uit verschillende bronnen om een meer omvattend begrip te ontwikkelen van de uitdagingen en best practices op dit gebied.
|
||||
Bedrijfsmatige Benaderingen van Diversiteit en Inclusie
|
||||
* De spreker bespreekt hun ervaring met diversiteit en inclusie-initiatieven bij CGI, waar ze deelnamen aan de Diversity Inclusion Committee.
|
||||
* Ze vermelden een tweedaagse training voor leiderschap over diversiteit en inclusie, die aanvankelijk aanzienlijke weerstand ondervond van sommige managers die de relevantie ervan voor hun primaire verantwoordelijkheden in twijfel trokken.
|
||||
* Deze weerstand creëerde bezorgdheid op het niveau van de directie over de mogelijke onpopulariteit van dergelijke initiatieven.
|
||||
* De spreker benadrukt het belang van betrokkenheid bij resistente individuen om hun zorgen te begrijpen en hen te helpen inzien hoe ze mogelijk al bijdragen aan inclusiviteit op manieren die ze zich niet realiseerden.
|
||||
Respellion's Benadering van Inclusiviteit
|
||||
* Raymond, van Respellion, beschrijft de unieke benadering van hun bedrijf om inclusiviteit te bevorderen.
|
||||
* Respellion, een jaar oud bedrijf met 15 medewerkers, combineert ervaringen van zowel kleine organisaties als multinationale ondernemingen.
|
||||
* Ze hebben een zelforganiserende cultuur geïmplementeerd met hoge autonomie voor medewerkers en zonder hiërarchische structuur.
|
||||
* Het bedrijf is verdeeld in drie 'huddles' van elk vijf personen, die dienen als vertrouwensgroepen.
|
||||
* Deze huddles hebben regelmatige check-ins en bi-monthly ontwikkelingsplanbesprekingen, die aspecten van professioneel, persoonlijk en fysiek welzijn behandelen.
|
||||
* Deze structuur biedt een veilige ruimte waar kwesties, inclusief die met betrekking tot inclusiviteit en diversiteit, kunnen worden aangekaart en aangepakt.
|
||||
Proactieve Inclusiviteitsmaatregelen
|
||||
* Raymond benadrukt het belang van het proactief aanpakken van inclusiviteitskwesties.
|
||||
* Hij geeft een voorbeeld van hoe Respellion omgaat met dieetvoorkeuren: ze hebben een standaardbeleid van vegetarische opties voor alle evenementen, met de mogelijkheid voor individuen om alternatieven aan te vragen indien nodig.
|
||||
* Deze aanpak verschuift de last van minderheidsgroepen die constant voor zichzelf moeten pleiten.
|
||||
* Raymond benadrukt het belang van het maken van duidelijke uitspraken en het creëren van wrijving voor degenen die niet direct door inclusiviteitskwesties worden getroffen, aangezien dit noodzakelijk is om verandering te stimuleren.
|
||||
Omgaan met Microagressies en Ongepaste Opmerkingen
|
||||
* De discussie behandelt het belang van het onmiddellijk aanpakken van microagressies of ongepaste opmerkingen op de werkplek.
|
||||
* Raymond geeft een voorbeeld van hoe hij een situatie heeft aangepakt waarin een oudere medewerker een seksistische opmerking maakte over secretariële werkzaamheden.
|
||||
* Hij benadrukt de noodzaak voor leiders om dergelijke kwesties openlijk in groepsinstellingen aan te pakken, zelfs als dit ongemak creëert.
|
||||
* Het doel is om het aanpakken van deze kwesties een normaal onderdeel van de werkcultuur te maken, in plaats van ze te vermijden of privé aan te pakken.
|
||||
Ervaringsgericht Leren voor Inclusiviteit
|
||||
* Beide sprekers zijn het erover eens dat ervaringsgericht leren belangrijk is om een echt begrip van inclusiviteitskwesties te bevorderen.
|
||||
* Ze bespreken de beperkingen van traditionele trainingsprogramma's, vooral die via online platforms worden aangeboden.
|
||||
* In plaats daarvan pleiten ze voor benaderingen die individuen in staat stellen te ervaren hoe het voelt om uitgesloten te worden of discriminatie te ondervinden.
|
||||
* Dit kan inhouden dat er rollenspellen, familieconstellaties of andere methoden worden gebruikt die viscerale ervaringen van ongelijkheid of uitsluiting creëren.
|
||||
* De sprekers geloven dat dergelijke ervaringen cruciaal zijn voor het ontwikkelen van empathie en het stimuleren van echte verandering in attitudes en gedragingen.
|
||||
Leiderschap en Coaching voor Inclusiviteit
|
||||
* Raymond benadrukt de rol van leiders als coaches in het bevorderen van een inclusieve omgeving.
|
||||
* Hij suggereert dat organisaties in plaats van grootschalige trainingsprogramma's, zich moeten richten op kleinschalige, intieme coachingsessies.
|
||||
* Dit kan inhouden dat teamcoaches in real-time situaties observeren en ingrijpen, waardoor leiders en teamleden in staat worden gesteld om inclusiviteitskwesties aan te pakken zodra ze zich voordoen.
|
||||
* Het doel is om discussies over inclusiviteit een natuurlijk onderdeel van dagelijkse interacties op de werkplek te maken, in plaats van geïsoleerde trainingsevenementen.
|
||||
Uitdagingen bij het Implementeren van Inclusiviteitsinitiatieven
|
||||
* De sprekers bespreken verschillende uitdagingen bij het implementeren van effectieve inclusiviteitsinitiatieven, waaronder weerstand van sommige medewerkers, de moeilijkheid om ingesleten culturele normen te veranderen, en de beperkingen van een one-size-fits-all benadering van training.
|
||||
* Ze benadrukken de noodzaak van op maat gemaakte, contextspecifieke interventies die rekening houden met de unieke dynamiek van elk team of organisatie.
|
||||
* De conversatie raakt ook het belang van het aanpakken van neurodiversiteit en verschillende leerstijlen bij het ontwerpen van inclusiviteitsprogramma's.
|
||||
|
||||
103
knowledge-base/Respellion Company Introduction.txt
Normal file
103
knowledge-base/Respellion Company Introduction.txt
Normal file
@@ -0,0 +1,103 @@
|
||||
# Respellion: Responsible Rebellion in Softwareontwikkeling
|
||||
|
||||
Respellion is een softwareontwikkelingsbedrijf opgericht door voormalige leiders van QDelft (dat later werd overgenomen door Netcompany Denemarken). Het bedrijf positioneert zichzelf als "responsible rebels", waarbij innovatieve benaderingen worden gecombineerd met een sterk gevoel voor maatschappelijke verantwoordelijkheid. Deze onderscheidende combinatie wordt weerspiegeld in hun naam - een samenvoeging van "verantwoordelijkheid" en "rebellie".
|
||||
|
||||
### Doel en Waarden
|
||||
|
||||
De kern van Respellion's identiteit is hun doel: "Een maatschappij waarin open-source technologie wordt ingezet om op een duurzame manier digitalisering mogelijk te maken." Dit doel is ontstaan uit brainstormsessies waarin de oprichters overwogen wat werkelijk belangrijk voor hen was. Raymond Verhoef beschrijft dit doel als "bestendig", omdat het consequent aansluit bij het werk dat ze uitvoeren.
|
||||
|
||||
Dit doel manifesteert zich concreet in hun klanten en projectkeuzes. Hun werk met het CIBG, diverse Ministeries en de gemeente Den Haag omvat het ontwikkelen van producten die de samenleving direct ten goede komen. Raymond legde uit: "We bouwen software die burgers in staat stelt om elkaar te helpen." Dit concept van helpen strekt zich uit tot zowel het ondersteunen van klanten als het creëren van software die burgers in staat stelt elkaar te ondersteunen.
|
||||
|
||||
Het bedrijf opereert volgens vier kernwaarden die het dagelijks gedrag sturen:
|
||||
|
||||
**Vertrouwen** wordt gedemonstreerd door transparantie en openheid. Tijdens de onboarding deelde Raymond een voorbeeld waarin Patrick te laat kwam op een vergadering met Thomas, die vroeg was opgestaan om aanwezig te zijn. In plaats van de situatie te negeren, erkenden ze het probleem onmiddellijk: "We legden het direct op tafel... omdat we voor elkaar moeten zorgen." Deze transparantie voorkomt dat kleine irritaties zich in de loop van de tijd opbouwen.
|
||||
|
||||
**Moed** houdt in dat men durft af te wijken van traditionele benaderingen en fouten omarmt als leermogelijkheden. De "rebelse" aard van het bedrijf komt tot uiting in hun bereidheid om gevestigde praktijken ter discussie te stellen wanneer ze geloven dat er een betere manier is.
|
||||
|
||||
**Zelfdiscipline** komt tot uiting in het nakomen van toezeggingen en het nemen van verantwoordelijkheid. Raymond benadrukte het belang hiervan "omdat het echt moeilijk is om in lijn te blijven met bepaalde waarden." Bij Respellion betekent dit zich goed voorbereiden op vergaderingen, op tijd komen en toezeggingen nakomen.
|
||||
|
||||
**Ondernemerschap** wordt aangemoedigd omdat iedereen "een stukje van de organisatie" op zich neemt. Met minimale managementrollen moeten teamleden een ondernemende mentaliteit aannemen. Zoals Raymond uitlegde: "Je moet bereid zijn om zelf een stukje van de organisatie op je te nemen."
|
||||
|
||||
Deze waarden komen tot uiting in hun manifest, dat vier gedragsprincipes schetst:
|
||||
|
||||
1. **Voortdurend in beweging blijven om wendbaar te blijven**: Dit wordt belichaamd in hun holacratische structuur, die zich regelmatig aanpast aan veranderende behoeften.
|
||||
|
||||
2. **Samenwerken op basis van gemeenschappelijke belangen in plaats van individueel gewin**: Raymond gaf een concreet voorbeeld: "Als we iets dubbel hebben gefactureerd, moet ik daar dan over zwijgen? Nee. Zou ik dat zelf willen? Nee. Dus ik werk samen op basis van ons gemeenschappelijk belang." Dit principe strekt zich uit tot klantrelaties, waar transparantie soms betekent dat ze hun eigen fouten aanwijzen.
|
||||
|
||||
3. **Werken met een glimlach en een zorgende houding**: Kleine gebaren demonstreren dit principe, zoals bloemen meenemen voor verjaardagen of koekjes voor vergaderingen. Raymond vermeldde: "Ik wil een organisatie zijn waar mensen zich verzorgd voelen."
|
||||
|
||||
4. **Streven naar evenwicht tussen mensen, planeet en winst**: Dit principe beïnvloedt hun klantenselectieproces. Tijdens de onboarding besprak Raymond hoe ze zorgvuldig overwegen of ze werk van bepaalde klanten accepteren op basis van afstemming met hun waarden. Ze wezen bijvoorbeeld een kans bij Holland Casino af tijdens Raymonds vakantie, wat hij waardeerde: "Dat zou ik ook niet hebben gedaan." Ook bespraken ze of ze werk van Shell zouden accepteren, concluderend dat dergelijke beslissingen een expliciete redenering vereisen, ongeacht de uitkomst.
|
||||
|
||||
### Holacracy: Een Dynamische Organisatiestructuur
|
||||
|
||||
Respellion heeft Holacracy geïmplementeerd, een zelfsturend organisatiesysteem dat traditionële hiërarchie vervangt door een flexibelere, adaptieve structuur. Raymond Verhoef, een van de oprichters, beschrijft deze benadering als vergelijkbaar met tuinieren in plaats van bouwen - condities creëren voor groei in plaats van bouwen volgens rigide plannen.
|
||||
|
||||
Belangrijke kenmerken van hun holacratische benadering zijn:
|
||||
- Organisatie via rollen in plaats van functietitels
|
||||
- Besluitvorming gebaseerd op commitment in plaats van consensus
|
||||
- Regelmatige governance-vergaderingen om de organisatiestructuur aan te passen
|
||||
- Tactische vergaderingen om operationele problemen aan te pakken
|
||||
|
||||
Het Holacracy-model stelt Respellion in staat om wendbaar te blijven terwijl het teamleden autonomie biedt. Zoals Raymond uitlegt, wordt "de stem van de minderheid altijd in aanmerking genomen" in besluitvormingsprocessen. Wijzigingen in rollen worden gemaakt tijdens governance-vergaderingen wanneer iemand een kloof identificeert tussen de huidige structuur en wat nodig is om verantwoordelijkheden effectief te vervullen.
|
||||
|
||||
### Coaching Cultuur
|
||||
|
||||
Respellion heeft een onderscheidende coachingcultuur ontwikkeld waarbij professionele en persoonlijke ontwikkeling zijn geïntegreerd. Deze cultuur manifesteert zich door verschillende gestructureerde praktijken:
|
||||
|
||||
1. **Huddle Check-ins**: Tweewekelijkse bijeenkomsten met kleine, consistente groepen voor snelle verbindingen en ondersteuning
|
||||
2. **Elevator Sessies**: Tweemaandelijkse gefaciliteerde coachingsessies gericht op persoonlijke ontwikkeling
|
||||
3. **Celebrations**: Tweemaandelijkse bijeenkomsten om successen te delen en, opmerkelijk, de "meest rebelse mislukking van de maand" - wat leren door falen aanmoedigt
|
||||
4. **Persoonlijke Ontwikkelingsplannen**: Gebouwd rond drie capaciteiten:
|
||||
- Professionele/intellectuele groei
|
||||
- Emotionele ontwikkeling (communicatie, feedback, triggers begrijpen)
|
||||
- Fysiek welzijn
|
||||
|
||||
Het persoonlijke ontwikkelingsproces is gebaseerd op Daniel Ofman's Kernkwaliteiten model, wat teamleden helpt hun sterke punten, valkuilen, uitdagingen en allergieën (reacties op gedragingen tegenovergesteld aan hun uitdagingen) te identificeren. Dit raamwerk biedt een gemeenschappelijke taal voor ontwikkelingsgesprekken.
|
||||
|
||||
### Diensten en Expertise
|
||||
|
||||
Respellion richt zich op drie primaire dienstgebieden:
|
||||
1. **Resultaatgerichte projecten**: Gebruik van Agile methodologieën gecombineerd met gestructureerd projectmanagement
|
||||
2. **High-performance teams**: Het leveren van multidisciplinaire teams met de technische en soft skills om complete oplossingen te leveren
|
||||
3. **Consultancy**: Het bieden van strategisch advies en technische expertise
|
||||
|
||||
Hun expertisegebieden omvatten:
|
||||
- Missiekritische systemen met hoge beschikbaarheid
|
||||
- Continuous Integration/Continuous Deployment (CI/CD)
|
||||
- Privacy en Security by Design
|
||||
- Digitale toegankelijkheid en bruikbaarheid
|
||||
- Agile projectmanagement en coaching
|
||||
- Duurzaam applicatiebeheer
|
||||
|
||||
### Werkomgeving en Medewerkerservaring
|
||||
|
||||
Respellion biedt een onderscheidende werkomgeving voor professionals die autonomie en zingeving zoeken in hun carrière. De combinatie van professionele excellentie met mensgerichte waarden creëert een unieke werkcultuur.
|
||||
|
||||
De medewerkerservaring bij Respellion wordt gekenmerkt door verschillende sleutelelementen:
|
||||
|
||||
- **Echte autonomie**: Via Holacracy nemen teamleden rollen op zich die aansluiten bij hun sterke punten en interesses, in plaats van in voorgedefinieerde functieomschrijvingen te passen. Dit stelt mensen in staat hun werk vorm te geven volgens hun talenten en ambities.
|
||||
|
||||
- **Groeigericht cultuur**: De coachingbenadering zorgt voor continue persoonlijke en professionele ontwikkeling. Regelmatige feedback en gestructureerde ontwikkelingssessies helpen teamleden zich in meerdere dimensies te ontwikkelen.
|
||||
|
||||
- **Doelgericht werk**: Teamleden dragen bij aan maatschappelijk waardevolle projecten met duurzame, open-source technologie, wat betekenis creëert die verder gaat dan commercieel succes.
|
||||
|
||||
- **Veilige leeromgeving**: Het vieren van "meest rebelse mislukkingen" toont een oprechte toewijding aan leren en versterkt psychologische veiligheid binnen teams.
|
||||
|
||||
Teamleden die gedijen bij Respellion waarderen typisch vertrouwen, tonen moed, beoefenen zelfdiscipline en omarmen ondernemerschap. Ze excelleren wanneer ze initiatiefmogelijkheden krijgen en zijn comfortabel met de verantwoordelijkheid die met autonomie komt.
|
||||
|
||||
Voor specialisten in open-source ontwikkeling die willen dat hun werk een bredere positieve impact heeft, biedt Respellion een alternatief voor traditionele bedrijfsstructuren terwijl het professionele nauwkeurigheid en marktconcurrentievermogen behoudt.
|
||||
|
||||
### Open-Source Filosofie
|
||||
|
||||
Respellion is diep toegewijd aan open-source technologie, wat aansluit bij hun duurzaamheidsdoelen. Ze waarderen open-source voor:
|
||||
- Transparantie en vertrouwensopbouwend potentieel
|
||||
- Samenwerkingsmogelijkheden met partners
|
||||
- Verbeterde beveiliging door community toezicht
|
||||
- Kostenefficiëntie en versnelling van innovatie
|
||||
- Flexibiliteit en onafhankelijkheid van leveranciers
|
||||
|
||||
### Huidige Status en Groeiplannen
|
||||
|
||||
Per 2025 heeft Respellion 15 teamleden bereikt en is van plan om te groeien naar 30 collega's in 2026. Deze gerichte groei is ontworpen om hen in staat te stellen complete ontwikkelteams te vormen die kunnen worden ingezet bij klantorganisaties.
|
||||
|
||||
Het bedrijf heeft zich gevestigd bij klanten waaronder gemeenten (Den Haag), overheidsinstanties (CBG, VWS), en andere organisaties zoals IKTU en Vooron. Ze opereren vanuit Haktech, een technologiegericht kantoorgebouw met andere innovatieve bedrijven.
|
||||
BIN
knowledge-base/Welcome-to-Respellion.pdf
Normal file
BIN
knowledge-base/Welcome-to-Respellion.pdf
Normal file
Binary file not shown.
@@ -1,62 +0,0 @@
|
||||
/// <reference path="../pb_data/types.d.ts" />
|
||||
//
|
||||
// Issue #18 — Reconcile the Entra (Azure) OIDC provider from the environment.
|
||||
//
|
||||
// The team_members→auth migration (pb_migrations/1781000000) is structure-only
|
||||
// and runs exactly once. Provider CONFIGURATION lives here instead, so that:
|
||||
//
|
||||
// * an environment whose migration applied while the ENTRA_* secrets were
|
||||
// absent gets its provider enabled on the next startup (no re-apply),
|
||||
// * rotating ENTRA_CLIENT_SECRET / changing the tenant only requires new env
|
||||
// values and a container restart,
|
||||
// * a fresh database gets its provider on the first cron tick right after
|
||||
// the migrations created the collection (onBootstrap fires BEFORE the
|
||||
// migrations run — there is no post-migration lifecycle hook in the JSVM,
|
||||
// hence the cron fallback).
|
||||
//
|
||||
// The reconciler compares before saving, so both hooks are cheap no-ops when
|
||||
// everything is already in sync.
|
||||
|
||||
onBootstrap((e) => {
|
||||
e.next();
|
||||
const { reconcileEntraOidc } = require(`${__hooks}/utils.js`);
|
||||
// reconcileEntraOidc logs a warn-once itself when the ENTRA_* env is absent.
|
||||
console.log("entra_oidc reconcile (bootstrap): " + reconcileEntraOidc(e.app));
|
||||
});
|
||||
|
||||
cronAdd("entraOidcReconcile", "* * * * *", () => {
|
||||
const { reconcileEntraOidc } = require(`${__hooks}/utils.js`);
|
||||
const result = reconcileEntraOidc($app);
|
||||
// Only log state changes — this tick runs every minute.
|
||||
if (result === "updated") {
|
||||
console.log("entra_oidc reconcile (cron): OIDC provider (re)configured from ENTRA_* env");
|
||||
}
|
||||
});
|
||||
|
||||
// Entra does not always supply an `email` claim: the id_token only carries it
|
||||
// when the account has a mail attribute (issue #24). The UPN in
|
||||
// `preferred_username` is always present and equals the primary e-mail for
|
||||
// Respellion organisation accounts, so fall back to it when it looks like a
|
||||
// real address. Guest UPNs ("user_ext#EXT#@tenant...") fail the regex on
|
||||
// purpose — those still get a clear validation error instead of a bogus email.
|
||||
// The catch also surfaces the underlying OAuth2 failure in the container log,
|
||||
// which PocketBase otherwise only writes to its internal logs database.
|
||||
onRecordAuthWithOAuth2Request((e) => {
|
||||
const u = e.oAuth2User;
|
||||
if (u && !u.email) {
|
||||
const upn = String((u.rawUser && u.rawUser.preferred_username) || u.username || "").trim().toLowerCase();
|
||||
// `#` is RFC-valid in an e-mail local part, so guest UPNs
|
||||
// ("ext_user#EXT#@tenant.onmicrosoft.com") pass a naive e-mail check AND
|
||||
// PocketBase's own validation — exclude them explicitly.
|
||||
if (/^[^@\s#]+@[^@\s#]+\.[^@\s#]+$/.test(upn)) {
|
||||
u.email = upn;
|
||||
console.log("entra_oidc: email claim absent — falling back to UPN " + upn);
|
||||
}
|
||||
}
|
||||
try {
|
||||
e.next();
|
||||
} catch (err) {
|
||||
console.log("entra_oidc auth-with-oauth2 FAILED:", String(err));
|
||||
throw err;
|
||||
}
|
||||
}, "team_members");
|
||||
@@ -15,16 +15,17 @@
|
||||
// The allow-list is a comma-separated list of e-mail addresses, e.g.:
|
||||
// ENTRA_ADMIN_EMAILS=rve@respellion.nl,admin@respellion.nl
|
||||
//
|
||||
// resolveRole itself lives in pb_hooks/utils.js and is pulled in per-callback
|
||||
// via require() — PocketBase's JSVM runs each hook callback below as its own
|
||||
// isolated program, so a shared top-level function here would not be in scope
|
||||
// at call time. See pb_hooks/utils.js for details. Keep the logic in sync with
|
||||
// src/lib/azureAuth.js (resolveRole / parseAdminEmails), which carries the
|
||||
// canonical, unit-tested version for the frontend/tests.
|
||||
// Keep this logic in sync with src/lib/azureAuth.js (resolveRole / parseAdminEmails),
|
||||
// which carries the canonical, unit-tested version for the frontend/tests.
|
||||
|
||||
function resolveRole(email) {
|
||||
const raw = ($os.getenv("ENTRA_ADMIN_EMAILS") || "").toLowerCase();
|
||||
const allow = raw.split(",").map(function (s) { return s.trim(); }).filter(Boolean);
|
||||
return allow.indexOf((email || "").toLowerCase()) !== -1 ? "admin" : "user";
|
||||
}
|
||||
|
||||
// On creation (first login): set defaults before the record is persisted.
|
||||
onRecordCreate(function (e) {
|
||||
const { resolveRole } = require(`${__hooks}/utils.js`);
|
||||
const email = e.record.get("email") || "";
|
||||
|
||||
e.record.set("role", resolveRole(email));
|
||||
@@ -44,7 +45,6 @@ onRecordCreate(function (e) {
|
||||
// On every successful auth (incl. OIDC): keep the admin role in sync with the
|
||||
// allow-list, so promoting/demoting an admin only requires an env change.
|
||||
onRecordAuthRequest(function (e) {
|
||||
const { resolveRole } = require(`${__hooks}/utils.js`);
|
||||
const email = e.record.get("email") || "";
|
||||
const want = resolveRole(email);
|
||||
if (e.record.get("role") !== want) {
|
||||
|
||||
@@ -1,109 +0,0 @@
|
||||
/// <reference path="../pb_data/types.d.ts" />
|
||||
//
|
||||
// Shared helpers for pb_hooks/*.pb.js callbacks.
|
||||
//
|
||||
// PocketBase's JSVM serializes and runs each registered hook callback as its
|
||||
// own isolated program, so a plain top-level function declared in a *.pb.js
|
||||
// file is NOT in scope inside a callback at call time. Reusable helpers must
|
||||
// instead live in a plain (non *.pb.js, so it isn't auto-loaded as a hook)
|
||||
// module and be pulled in per-callback via require(`${__hooks}/utils.js`).
|
||||
// See: https://github.com/pocketbase/pocketbase/discussions/3599
|
||||
//
|
||||
// Loaded modules use a shared registry across callback invocations, so keep
|
||||
// this file stateless. (Deliberate exception: the warn-once latch below, which
|
||||
// exists precisely BECAUSE the registry is shared — it dedupes the env-missing
|
||||
// warning across the bootstrap hook and the per-minute cron tick.)
|
||||
//
|
||||
// Keep resolveRole in sync with src/lib/azureAuth.js's resolveRole (the
|
||||
// canonical, unit-tested version used by the frontend).
|
||||
|
||||
let warnedEnvMissing = false;
|
||||
|
||||
module.exports = {
|
||||
/**
|
||||
* Resolve a user's role from their e-mail and the ENTRA_ADMIN_EMAILS allow-list.
|
||||
* @param {string} email
|
||||
* @returns {"admin"|"user"}
|
||||
*/
|
||||
resolveRole: function (email) {
|
||||
const raw = ($os.getenv("ENTRA_ADMIN_EMAILS") || "").toLowerCase();
|
||||
const allow = raw.split(",").map(function (s) { return s.trim(); }).filter(Boolean);
|
||||
return allow.indexOf(String(email || "").toLowerCase()) !== -1 ? "admin" : "user";
|
||||
},
|
||||
|
||||
/**
|
||||
* Reconcile the Entra (Azure) OIDC provider on the team_members auth
|
||||
* collection from the ENTRA_* environment variables (issue #18).
|
||||
*
|
||||
* Idempotent: compares the desired provider config against the stored one
|
||||
* and only saves when something actually changed, so it is safe to call on
|
||||
* every bootstrap and cron tick. Keeping this OUT of the one-shot migration
|
||||
* means late or rotated secrets are picked up on the next start/tick without
|
||||
* any manual re-apply.
|
||||
*
|
||||
* @param {core.App} app
|
||||
* @returns {"collection-missing"|"not-auth-yet"|"env-missing"|"in-sync"|"updated"}
|
||||
*/
|
||||
reconcileEntraOidc: function (app) {
|
||||
let col;
|
||||
try {
|
||||
col = app.findCollectionByNameOrId("team_members");
|
||||
} catch (_) {
|
||||
return "collection-missing"; // migration has not created it yet
|
||||
}
|
||||
if (col.type !== "auth") {
|
||||
return "not-auth-yet"; // pre-conversion PIN-era collection
|
||||
}
|
||||
|
||||
const tenant = $os.getenv("ENTRA_TENANT_ID") || "common";
|
||||
const clientId = $os.getenv("ENTRA_CLIENT_ID") || "";
|
||||
const clientSecret = $os.getenv("ENTRA_CLIENT_SECRET") || "";
|
||||
if (!clientId || !clientSecret) {
|
||||
if (!warnedEnvMissing) {
|
||||
warnedEnvMissing = true;
|
||||
console.log(
|
||||
"WARN entra_oidc: ENTRA_CLIENT_ID / ENTRA_CLIENT_SECRET not set — Microsoft login stays " +
|
||||
"disabled until the env vars are provided (they are reconciled automatically on startup)."
|
||||
);
|
||||
}
|
||||
return "env-missing";
|
||||
}
|
||||
warnedEnvMissing = false; // env restored — re-arm the warning for future rotations
|
||||
|
||||
const desired = {
|
||||
name: "oidc",
|
||||
clientId: clientId,
|
||||
clientSecret: clientSecret,
|
||||
authURL: "https://login.microsoftonline.com/" + tenant + "/oauth2/v2.0/authorize",
|
||||
tokenURL: "https://login.microsoftonline.com/" + tenant + "/oauth2/v2.0/token",
|
||||
// Deliberately empty: claims are read from the Entra id_token instead of
|
||||
// Graph's /oidc/userinfo. The userinfo endpoint omits `email` for
|
||||
// accounts without a mail attribute, while the id_token always carries
|
||||
// `preferred_username` (UPN) which entra_oidc.pb.js uses as an e-mail
|
||||
// fallback (issue #24).
|
||||
userInfoURL: "",
|
||||
displayName: "Microsoft",
|
||||
pkce: true,
|
||||
};
|
||||
|
||||
const providers = (col.oauth2 && col.oauth2.providers) || [];
|
||||
const current = providers.length === 1 ? providers[0] : null;
|
||||
const inSync = !!current &&
|
||||
col.oauth2.enabled === true &&
|
||||
current.name === desired.name &&
|
||||
current.clientId === desired.clientId &&
|
||||
current.clientSecret === desired.clientSecret &&
|
||||
current.authURL === desired.authURL &&
|
||||
current.tokenURL === desired.tokenURL &&
|
||||
current.userInfoURL === desired.userInfoURL &&
|
||||
current.displayName === desired.displayName;
|
||||
if (inSync) {
|
||||
return "in-sync";
|
||||
}
|
||||
|
||||
col.oauth2.enabled = true;
|
||||
col.oauth2.providers = [desired];
|
||||
app.save(col);
|
||||
return "updated";
|
||||
},
|
||||
};
|
||||
@@ -1,138 +0,0 @@
|
||||
/// <reference path="../pb_data/types.d.ts" />
|
||||
//
|
||||
// Issue #18 — Baseline ledger sync for out-of-band provisioned databases.
|
||||
//
|
||||
// The Labs/production PocketBase originally ran WITHOUT --migrationsDir: its
|
||||
// schema was created by scripts/setup-pb-collections.mjs / the admin UI, so its
|
||||
// _migrations ledger is empty. When the migrations dir was mounted for the
|
||||
// first time (Azure SSO, PR #17), PocketBase tried to replay the entire
|
||||
// migration history against that existing schema and crash-looped on the very
|
||||
// first file ("Collection name must be unique").
|
||||
//
|
||||
// This migration sorts before every other file. When it detects that the
|
||||
// legacy schema already exists but the ledger has never tracked it, it marks
|
||||
// the historical migrations below as applied so the replay is skipped and the
|
||||
// chain continues with the genuinely new migrations (team_members_to_auth,
|
||||
// tighten_api_rules). On fresh databases and on databases that already have a
|
||||
// populated ledger it is a no-op.
|
||||
//
|
||||
// NOTE for future agents: never rename a migration file after it has been
|
||||
// applied anywhere — the ledger is filename-based. New migrations must sort
|
||||
// after 1781100001 and be appended to environments through a normal deploy.
|
||||
const HISTORICAL_MIGRATIONS = [
|
||||
"1778948471_created_content.js",
|
||||
"1778948471_created_quiz_banks.js",
|
||||
"1778948471_created_relations.js",
|
||||
"1778948471_created_sources.js",
|
||||
"1778948471_created_team_members.js",
|
||||
"1778948471_created_topics.js",
|
||||
"1778948472_created_leaderboard.js",
|
||||
"1778948472_created_learn_progress.js",
|
||||
"1778948472_created_quiz_cache.js",
|
||||
"1778948472_created_quiz_results.js",
|
||||
"1778948472_created_settings.js",
|
||||
"1778954289_created_test_col2.js",
|
||||
"1778954310_deleted_relations.js",
|
||||
"1778954310_deleted_topics.js",
|
||||
"1778954310_deleted_users.js",
|
||||
"1778954311_deleted_content.js",
|
||||
"1778954311_deleted_leaderboard.js",
|
||||
"1778954311_deleted_learn_progress.js",
|
||||
"1778954311_deleted_quiz_banks.js",
|
||||
"1778954311_deleted_quiz_cache.js",
|
||||
"1778954311_deleted_quiz_results.js",
|
||||
"1778954311_deleted_settings.js",
|
||||
"1778954311_deleted_sources.js",
|
||||
"1778954311_deleted_team_members.js",
|
||||
"1778954311_deleted_test_col2.js",
|
||||
"1778954317_created_content.js",
|
||||
"1778954317_created_leaderboard.js",
|
||||
"1778954317_created_learn_progress.js",
|
||||
"1778954317_created_quiz_banks.js",
|
||||
"1778954317_created_quiz_cache.js",
|
||||
"1778954317_created_quiz_results.js",
|
||||
"1778954317_created_relations.js",
|
||||
"1778954317_created_settings.js",
|
||||
"1778954317_created_sources.js",
|
||||
"1778954317_created_team_members.js",
|
||||
"1778954317_created_topics.js",
|
||||
"1779005271_created_test_col3.js",
|
||||
"1779005289_created_test_col4.js",
|
||||
"1779005309_deleted_content.js",
|
||||
"1779005309_deleted_learn_progress.js",
|
||||
"1779005309_deleted_quiz_banks.js",
|
||||
"1779005309_deleted_quiz_cache.js",
|
||||
"1779005309_deleted_quiz_results.js",
|
||||
"1779005309_deleted_relations.js",
|
||||
"1779005309_deleted_sources.js",
|
||||
"1779005309_deleted_team_members.js",
|
||||
"1779005309_deleted_topics.js",
|
||||
"1779005310_deleted_leaderboard.js",
|
||||
"1779005310_deleted_settings.js",
|
||||
"1779005310_deleted_test_col3.js",
|
||||
"1779005310_deleted_test_col4.js",
|
||||
"1779005316_created_content.js",
|
||||
"1779005316_created_quiz_banks.js",
|
||||
"1779005316_created_relations.js",
|
||||
"1779005316_created_sources.js",
|
||||
"1779005316_created_topics.js",
|
||||
"1779005317_created_leaderboard.js",
|
||||
"1779005317_created_learn_progress.js",
|
||||
"1779005317_created_quiz_cache.js",
|
||||
"1779005317_created_quiz_results.js",
|
||||
"1779005317_created_settings.js",
|
||||
"1779005317_created_team_members.js",
|
||||
"1779127586_created_curriculum.js",
|
||||
"1779127759_collections_snapshot.js",
|
||||
"1779200000_updated_sources.js",
|
||||
"1780000001_updated_topics.js",
|
||||
"1780500000_updated_topics_relevance_locked.js",
|
||||
"1780500001_normalize_relation_types.js",
|
||||
"1780500002_created_llm_calls.js",
|
||||
"1780600000_curriculum_v2.js",
|
||||
"1780700000_sources_progress.js",
|
||||
"1780800000_created_micro_learnings.js",
|
||||
"1780800001_deleted_legacy_collections.js",
|
||||
"1780800002_update_micro_learnings_rules.js",
|
||||
"1780900000_team_members_enrollment.js",
|
||||
"1780900001_created_test_results.js",
|
||||
"1781000000_created_theme_sessions.js",
|
||||
"1781100000_created_question_bank.js",
|
||||
"1781100001_created_on_demand_attempts.js",
|
||||
];
|
||||
|
||||
migrate((app) => {
|
||||
// Fresh database? (no legacy schema) -> let the normal chain run.
|
||||
try {
|
||||
app.findCollectionByNameOrId("content");
|
||||
} catch (_) {
|
||||
return;
|
||||
}
|
||||
|
||||
// Ledger already tracks the history? -> normally migrated DB, nothing to do.
|
||||
const probe = new DynamicModel({ count: 0 });
|
||||
app.db()
|
||||
.newQuery("SELECT COUNT(*) AS count FROM _migrations WHERE file = {:file}")
|
||||
.bind({ file: "1778948471_created_content.js" })
|
||||
.one(probe);
|
||||
if (probe.count > 0) {
|
||||
return;
|
||||
}
|
||||
|
||||
// Out-of-band provisioned database: schema exists, ledger is empty.
|
||||
// Mark the historical migrations as applied so they are not replayed.
|
||||
const applied = Date.now();
|
||||
for (const file of HISTORICAL_MIGRATIONS) {
|
||||
app.db()
|
||||
.newQuery("INSERT OR IGNORE INTO _migrations (file, applied) VALUES ({:file}, {:applied})")
|
||||
.bind({ file: file, applied: applied })
|
||||
.execute();
|
||||
}
|
||||
console.log(
|
||||
"baseline_ledger_sync: detected out-of-band provisioned database — marked " +
|
||||
HISTORICAL_MIGRATIONS.length + " historical migrations as applied"
|
||||
);
|
||||
}, (_app) => {
|
||||
// Down: intentionally a no-op. The ledger rows describe environment-specific
|
||||
// bookkeeping; removing them would re-trigger the replay this fix prevents.
|
||||
});
|
||||
@@ -1,6 +1,6 @@
|
||||
/// <reference path="../pb_data/types.d.ts" />
|
||||
//
|
||||
// Issue #16 / #18 — Azure (Entra ID) login.
|
||||
// Issue #16 — Azure (Entra ID) login.
|
||||
//
|
||||
// Replaces the PIN-based `base` collection `team_members` with a PocketBase
|
||||
// `auth` collection that authenticates against Azure Entra ID via OIDC.
|
||||
@@ -10,106 +10,34 @@
|
||||
// base, generated tests and micro-learnings live in OTHER collections and are
|
||||
// left completely untouched by this migration.
|
||||
//
|
||||
// This migration is STRUCTURE ONLY and does not depend on the environment:
|
||||
// the OIDC provider credentials (ENTRA_TENANT_ID / ENTRA_CLIENT_ID /
|
||||
// ENTRA_CLIENT_SECRET) are reconciled into the collection on every startup by
|
||||
// pb_hooks/entra_oidc.pb.js. That keeps the one-shot migration deterministic:
|
||||
// applying it while the secrets are absent can no longer permanently disable
|
||||
// OAuth2 (issue #18). As a fast path the provider is also attached here when
|
||||
// the env vars are already present at apply time.
|
||||
// OIDC provider credentials are read from the environment at apply time, so no
|
||||
// secrets are committed to git:
|
||||
// ENTRA_TENANT_ID, ENTRA_CLIENT_ID, ENTRA_CLIENT_SECRET
|
||||
// (set via the Ansible-rendered .env, see infra/*/site/compose.yml).
|
||||
//
|
||||
// To rotate credentials or change the tenant later, update the env and either
|
||||
// re-configure the provider from the PocketBase admin UI (Settings → Auth
|
||||
// providers) or ship a follow-up migration.
|
||||
migrate((app) => {
|
||||
// Idempotency guard: if team_members is already an auth collection (e.g. the
|
||||
// conversion happened through an earlier partial rollout), leave it alone.
|
||||
let existing = null;
|
||||
// 1. Drop the old PIN-based collection (takes the PIN records with it).
|
||||
try {
|
||||
existing = app.findCollectionByNameOrId("team_members");
|
||||
const old = app.findCollectionByNameOrId("team_members");
|
||||
app.delete(old);
|
||||
} catch (_) {
|
||||
existing = null; // collection absent — nothing to convert, only to create
|
||||
}
|
||||
if (existing && existing.type === "auth") {
|
||||
console.log("team_members_to_auth: team_members is already an auth collection — skipping conversion.");
|
||||
return;
|
||||
// Collection did not exist — nothing to drop.
|
||||
}
|
||||
|
||||
// 1. Detach relation fields that point at team_members. PocketBase refuses
|
||||
// to delete a collection that other collections relate to, so before we
|
||||
// can drop the old PIN-based team_members we convert those relations into
|
||||
// plain text fields (the id is stored as text — consistent with how
|
||||
// user_id is stored in test_results / on_demand_attempts). The column
|
||||
// values are preserved by the conversion.
|
||||
const deps = [
|
||||
{ name: "micro_learning_completions", relId: "rel_team_member_id", textId: "txt_mlc_team_member" },
|
||||
{ name: "theme_session_completions", relId: "rel_tsc_team_member", textId: "txt_tsc_team_member" },
|
||||
];
|
||||
for (const dep of deps) {
|
||||
let c = null;
|
||||
try {
|
||||
c = app.findCollectionByNameOrId(dep.name);
|
||||
} catch (_) {
|
||||
console.log("team_members_to_auth: " + dep.name + " does not exist yet — nothing to detach.");
|
||||
continue;
|
||||
}
|
||||
if (!c.fields.getById(dep.relId)) {
|
||||
console.log("team_members_to_auth: " + dep.name + "." + dep.relId + " already detached — skipping.");
|
||||
continue;
|
||||
}
|
||||
// PocketBase diffs fields by ID, so swapping the relation field for a text
|
||||
// field drops and recreates the underlying column. Back the values up and
|
||||
// restore them after the schema save — the ids must survive (issue #18).
|
||||
const backup = "_issue18_tm_" + dep.name;
|
||||
app.db().newQuery("DROP TABLE IF EXISTS `" + backup + "`").execute();
|
||||
app.db().newQuery(
|
||||
"CREATE TABLE `" + backup + "` AS SELECT `id`, `team_member_id` AS `v` FROM `" + dep.name + "`"
|
||||
).execute();
|
||||
|
||||
// Drop any index that references the team_member_id column (it is rebuilt
|
||||
// on the text column below).
|
||||
c.indexes = (c.indexes || []).filter((idx) => idx.indexOf("team_member_id") === -1);
|
||||
// Replace the relation field with a text field of the same name.
|
||||
c.fields.removeById(dep.relId);
|
||||
c.fields.add(new Field({
|
||||
type: "text",
|
||||
id: dep.textId,
|
||||
name: "team_member_id",
|
||||
required: false,
|
||||
min: 0,
|
||||
max: 0,
|
||||
}));
|
||||
app.save(c);
|
||||
|
||||
app.db().newQuery(
|
||||
"UPDATE `" + dep.name + "` SET `team_member_id` = COALESCE(" +
|
||||
"(SELECT `v` FROM `" + backup + "` WHERE `" + backup + "`.`id` = `" + dep.name + "`.`id`), '')"
|
||||
).execute();
|
||||
app.db().newQuery("DROP TABLE `" + backup + "`").execute();
|
||||
}
|
||||
|
||||
// Recreate the unique (team_member_id, session_week) guard on the text column.
|
||||
try {
|
||||
const tsc = app.findCollectionByNameOrId("theme_session_completions");
|
||||
const idx = "CREATE UNIQUE INDEX `idx_theme_session_completions_user_week` ON `theme_session_completions` (`team_member_id`, `session_week`)";
|
||||
if ((tsc.indexes || []).indexOf(idx) === -1) {
|
||||
tsc.indexes.push(idx);
|
||||
app.save(tsc);
|
||||
}
|
||||
} catch (_) {
|
||||
console.log("team_members_to_auth: theme_session_completions does not exist yet — no index to rebuild.");
|
||||
}
|
||||
|
||||
// 2. Drop the old PIN-based team_members (now unreferenced). NOT wrapped in
|
||||
// a try/catch: if this fails there is an unknown relation left and the
|
||||
// migration must fail loudly instead of masking the error (issue #18).
|
||||
if (existing) {
|
||||
app.delete(existing);
|
||||
}
|
||||
|
||||
// Fast path: attach the OIDC provider right away when the credentials are
|
||||
// already present at apply time. When they are absent the collection is
|
||||
// created without a provider and pb_hooks/entra_oidc.pb.js configures it on
|
||||
// the next startup / cron tick once the ENTRA_* env vars are supplied.
|
||||
const tenant = $os.getenv("ENTRA_TENANT_ID") || "common";
|
||||
const clientId = $os.getenv("ENTRA_CLIENT_ID") || "";
|
||||
const clientSecret = $os.getenv("ENTRA_CLIENT_SECRET") || "";
|
||||
const clientId = $os.getenv("ENTRA_CLIENT_ID");
|
||||
const clientSecret = $os.getenv("ENTRA_CLIENT_SECRET");
|
||||
|
||||
// Only configure the OIDC provider when credentials are actually present.
|
||||
// PocketBase rejects an enabled OAuth2 provider with an empty clientId /
|
||||
// clientSecret, which would abort this migration and prevent PocketBase from
|
||||
// starting at all (502 on every /api call). When the secrets are absent the
|
||||
// collection is created without a provider; once the ENTRA_* secrets are set,
|
||||
// configure the provider via the PocketBase admin UI
|
||||
// (Settings → Auth providers → OIDC) or re-apply this migration.
|
||||
const oidcProviders = (clientId && clientSecret) ? [
|
||||
{
|
||||
name: "oidc",
|
||||
@@ -117,21 +45,13 @@ migrate((app) => {
|
||||
clientSecret: clientSecret,
|
||||
authURL: "https://login.microsoftonline.com/" + tenant + "/oauth2/v2.0/authorize",
|
||||
tokenURL: "https://login.microsoftonline.com/" + tenant + "/oauth2/v2.0/token",
|
||||
// Empty on purpose: claims come from the id_token (see utils.js, issue #24).
|
||||
userInfoURL: "",
|
||||
userInfoURL: "https://graph.microsoft.com/oidc/userinfo",
|
||||
displayName: "Microsoft",
|
||||
pkce: true,
|
||||
},
|
||||
] : [];
|
||||
if (oidcProviders.length === 0) {
|
||||
console.log(
|
||||
"team_members_to_auth: ENTRA_CLIENT_ID / ENTRA_CLIENT_SECRET not set — creating the auth " +
|
||||
"collection without an OIDC provider. pb_hooks/entra_oidc.pb.js will configure the provider " +
|
||||
"automatically once the env vars are present (no re-apply needed)."
|
||||
);
|
||||
}
|
||||
|
||||
// 3. Recreate `team_members` as an auth collection (same name → all existing
|
||||
// 2. Recreate `team_members` as an auth collection (same name → all existing
|
||||
// `user_id` references in test_results, on_demand_attempts,
|
||||
// micro_learning_completions, leaderboard, theme_session_completions keep
|
||||
// working unchanged).
|
||||
@@ -143,14 +63,10 @@ migrate((app) => {
|
||||
// Access rules: every legitimate user is authenticated (Azure-gated +
|
||||
// OIDC). Profiles are readable by any authenticated user (leaderboard,
|
||||
// dashboard); a user may only update their own record (onboarding flips
|
||||
// enrollment_status). Record creation is ONLY allowed from within the
|
||||
// OAuth2 sign-up flow: PocketBase applies the createRule to the automatic
|
||||
// record creation on a first OIDC login, so `null` would make every first
|
||||
// login fail with 403 "Only superusers can perform this action" (issue
|
||||
// #22). Plain REST creates keep being rejected for non-superusers.
|
||||
// enrollment_status). Creation/deletion happen via OAuth2 / superuser only.
|
||||
listRule: '@request.auth.id != ""',
|
||||
viewRule: '@request.auth.id != ""',
|
||||
createRule: '@request.context = "oauth2"',
|
||||
createRule: null,
|
||||
updateRule: '@request.auth.id = id',
|
||||
deleteRule: null,
|
||||
authRule: "",
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
/// <reference path="../pb_data/types.d.ts" />
|
||||
//
|
||||
// Issue #22 — Allow OAuth2 sign-up on team_members.
|
||||
//
|
||||
// The collection was created with `createRule: null` on the assumption that
|
||||
// the OAuth2 flow bypasses it. It does not: PocketBase applies the createRule
|
||||
// to the automatic record creation on a first OIDC login, so every first
|
||||
// login failed with 403 "Only superusers can perform this action". Since the
|
||||
// pre-Azure records were intentionally dropped, EVERY user was a first login
|
||||
// and nobody could sign in.
|
||||
//
|
||||
// `@request.context = "oauth2"` scopes record creation to the OAuth2 flow
|
||||
// only — plain REST creates (e.g. anonymous POST /records, which could
|
||||
// otherwise pre-seed rogue admin profiles) keep being rejected.
|
||||
//
|
||||
// Environments that have not applied 1781000000 yet get this rule directly
|
||||
// from that (updated) migration; this follow-up exists for databases where it
|
||||
// already ran with the old `null` rule (Labs). Applying it twice is harmless.
|
||||
migrate((app) => {
|
||||
let col;
|
||||
try {
|
||||
col = app.findCollectionByNameOrId("team_members");
|
||||
} catch (_) {
|
||||
console.log("allow_oauth2_signup: team_members does not exist — skipping.");
|
||||
return;
|
||||
}
|
||||
if (col.type !== "auth") {
|
||||
console.log("allow_oauth2_signup: team_members is not an auth collection — skipping.");
|
||||
return;
|
||||
}
|
||||
col.createRule = '@request.context = "oauth2"';
|
||||
app.save(col);
|
||||
}, (app) => {
|
||||
// Down: restore the (broken) superuser-only rule.
|
||||
let col;
|
||||
try {
|
||||
col = app.findCollectionByNameOrId("team_members");
|
||||
} catch (_) {
|
||||
return;
|
||||
}
|
||||
if (col.type !== "auth") {
|
||||
return;
|
||||
}
|
||||
col.createRule = null;
|
||||
app.save(col);
|
||||
});
|
||||
@@ -111,9 +111,6 @@ const COLLECTIONS = [
|
||||
name: 'team_members',
|
||||
type: 'auth',
|
||||
...OPEN_RULES,
|
||||
// Mirror of pb_migrations/1781000002: creation only via the OAuth2
|
||||
// sign-up flow (issue #22).
|
||||
createRule: '@request.context = "oauth2"',
|
||||
passwordAuth: { enabled: false, identityFields: ['email'] },
|
||||
fields: [
|
||||
{ name: 'name', type: 'text', required: false },
|
||||
|
||||
Reference in New Issue
Block a user