V2 organization.

[riderx]

The current release of ORG is a MVP of a bigger change created in Capgo.

the end goal is to make organizations owner of the apps and owners of billing profiles.

for now apps, storage and billing profile are all linked to the org owner and not the org itself, this is problematic for the evolution of the product and should me migrated to ORGS

In this migration we have to completely decolerate users and orgs, it’s mean we can have from one to infinite admin and we can remove original one without issue.

this has to be fully tested. The CLI and the doc should be updated as well.

[riderx]

There is a question about API keys. maybe link to orgs and users instead of just users, that would simplify the RLS

[WcaleNieWolny]

The question is how granular do you want the permission system to be. Depending on the answer the complexity of this migration changes

Do you want the permissions to split all the way to individual apps? Meaning: Do you want a user to be able to invite a diffrent user ONLY to 1 app? For me this is an obvious yes

Do you want the permission to split all the way to individual channels?

This is the point where we should stop - the complexity is way to high and I doubt anyone will use this feature. If we implement the split all the way to individual apps properly then we COULD conciser adding this in further revision

Do we want the permission to split all the way to individual versions?

This is by far the most complex system we could implement - it's so complex it would take months to develop. I am strongly against implementing it - NO ONE will use this

The next questions is about having multiple organizations with the same email

The first question is about the capgo trial - how can a user who is on capgo trial create more then 1 organization? Well, if the billing is linked to org and NOT to user then creating a new org should start a new trial right? But that does make any sense - it gives unlimited trial So, perhaps we can keep the trial linked to the user and when he creates a new org the billing will inherit the trial of the owner. Meaning that if you have 7 days of trial left and you create a new org that org will have 7 days of trial added into it.

Then let's say that you want to have an overlap. This is no possible, you cannot just "borrow" an app You cannot decide that Org C should have access to App "smile" In this scenario it's not possible to determine billing for app "smile"

So, we have to add an option to transfer apps

Overall, I think that we should plan two versions of orgs:

V2:

• we add permissions split all the way to individual apps
• We move billing to orgs
• We rewrite RLS to remove tech debt

V3:

• We add the ability to create multiple orgs per email
• We add the app transfer

[riderx]

For now the granularity is out of scope. We keep only the org level rights active and keep the rest for later. We do not talk about allowing user to create a second org for now, it’s still out of scope. So trial are link to org creation for simplicity, but users can’t create multiple org anyway for now. In a next release we will see the trial problem. No transfer app for now.

[riderx]

If admin delete other admins and the user has no more org we force recreate one

[WcaleNieWolny]

Granularity has to be implemented when thinking about a rewrite/orgs v2 - even if we do not allow the invitation of a user to only one app. Here is how I see it

Then when we ask ourselves if user X has access to resource Y we do:

It we don't do it like that and instead replace user_id with org_id then it will not be possible to add granularity in further release due to complexity. We need to think about how we are going to evolve the orgs sytem

My proposal will remove A LOT of tech debt that is currently in the RLS

[riderx]

It doesn’t have to be implemented for what we try to solve in step 2. The v2 could be done in a day or 2 the way I propose it, your proposal will take more time and I’m not a fan of ditching the whole architecture I started to implement early on with only one table. Without any explanation of how this is failing to serve our goal

[WcaleNieWolny]

After a lot of thinking I do see how we can expand on what you are trying to do. Even adding granularity. The only issue i see are app transfers but that is tech debt for future us. Can we do something like this in the rewrite to simplify API keys RLS?:

[riderx]

i'm not sure to understand what do you try to achieve with this?

[WcaleNieWolny]

having 1 rls for both api keys and auth.uid so that we don't have to have 2 different rls policies

[riderx]

oh yes that make a lot of sense