Organization plugin for multi-org support

[mdwt]

I'm working on a plugin to add support for organisations - multi-orgs per user, organisation CRUD, member invite, etc., planning to PR.

I'm specifically excluding any roles so RBAC is done via callback. The plugin only manages the orgs and memberships.

Firstly, I want to check if this is something that you're planning or working on?

Secondly, this requires tracking the active org ID in the session to allow them to switch and also have multiple sessions with different orgs. This requires the plugin schema to update in the TS client (and stores etc.) to have the session data available which is currently only user object. It also has some other downstream effects on other plugins, e.g. session-jwt, which doesn't have the session available when minting a JWT. For my case cookie auth is fine, but it means that session-jwt doesn't support having an active org in the session.

export type PluginSchema = {
  user?: object;
  session?: object;
};

I want to discuss and check if there's anything I'm missing before I start adding it everywhere where it's needed. It seems like a fair thing to assume that both the user and session data are available throughout.

Here's the fork for reference - https://github.com/mdwt/limen/tree/organizations-plugin

[thecodearcher]

Hey, thanks for reaching out before going deep, and for sharing the fork.

Quick heads-up on both fronts: yes, an organizations plugin is something we're actively working on, so there'd be a lot of overlap. There are also some breaking changes coming to core (mainly around how queries/relations work) that the org plugin will build on, so anything wired against the current core, especially cross-cutting session changes, would likely need reworking soon after.

So I'd hold off on this one. Keep an eye on the repo, the core changes should land soon.

Thanks for the initiative!

[mdwt]

ok great, looking forward to it :)

One thing i noticed is there's no support for DB level hooks to sync data from Limen to app level tables, e.g. when having separate limen_{users, orgs, members} and app_{users,orgs,members} tables that need to sync. also things like outbox style domain events that needs to save in the same transaction.

I know the HTTP-level hooks exist, but it would be great if the app could pass in the transaction like WithExternalTx(ctx, tx) and have data-layer before/after hooks

btw I'm using pgx and Fuego (net/http) and it was easy get it into the app

[thecodearcher]

🤔 why the separate limen_* and app_* tables though? Limen just writes to your own tables (you can rename them and add columns as you please).

[mdwt]

it's a design preference to allow multiple auth adapters without leaking auth specific implementation into the app model.. keeping the tables separate makes it easier to extend and adapt, at the cost of needing to sync data - which is ok in this instance..

also things like ids - limen uses uuid, system uses time sortable ids like ksuid

[thecodearcher]

hmm...both reasons you gave kind of dissolve against how limen actually works:

• ids — limen doesn't default to uuid, primary keys are BIGINT auto-increment out of the box. and it's fully pluggable: WithSchemaIDGenerator takes any generator, so drop in a ksuid one and limen mints ksuids straight into your tables. there's no id format mismatch to sync in the first place.

• auth impl leaking into the app model — it doesn't leak. limen writes to your tables, you rename them and add whatever columns you want. the auth adapter is swappable underneath without your app_* schema ever seeing it, because there is no separate limen schema, it's just your tables.

so the limen_* → app_* sync isn't buying you isolation you don't already have, it's introducing a two-write consistency problem out of a setup that doesn't need one. limen writes direct to your tables, so there's nothing to mirror.

[mdwt]

like I said it's a preference :) in some systems you dont want the core domain schema to host auth-mechanism columns

it's very doable with data-layer hooks (like better-auth does on node), and the hooks have other useful cases as well

I hope that's something we can add to the framework