Modeling tenants and members, plus ReBAC and PWA offline sync
Modeled companies, members, and roles for a multitenant client system and read-only reference tables for cities and states, and wrote about ReBAC and how PWA offline sync replays data.
A day of modeling access and ownership, and of writing about the two halves of it: who can do what, and what happens when the network drops.
Client project (NDA)
I kept working the multitenant model.
The cleaner shape is a members table that relates to companies rather than an embedded company-member structure, because the same person can work for more than one company, sometimes as a hired service.
Roles fell out as manager, pilot, technician, and support.
I also modeled reference tables for states and cities: two tables (estado and municipio) instead of one wide table, keyed properly, and dropped the external code column that did nothing for us.
The practical side was opening a legacy Access database in DBeaver and saving a clean DDL, plus merging main and resolving conflicts.
tgmarinho-ai-website
I wrote a post on ReBAC (relationship-based access control), using an open-source permissions engine as the reference for how a single core can express RBAC, ABAC, and ReBAC at once: a rule is either a condition on the record, a walk across a relationship, or a check that a field equals the actor.
Then I went deep on the offline half of a PWA. A reader made a sharp point: most PWAs cache the shell and stop, so they open offline but show nothing. The real work is IndexedDB plus replay. I dug into the full flow: install the app, hold data locally, let people act offline, then sync when they are back online, including who listens for the network returning and what triggers the queued writes back to the API. A quick pass on JWT rounded out the day.
The connective tissue: permissions and offline sync are both about trusting a decision made earlier, in another context, and honoring it correctly later.