RFC: Adding 'organisation' support for users and spaces about docq HOT 11 CLOSED

Re: multi-tenancy for SaaS discussion. This is probably the solution. Use Organisation as the partition key for everything.

from docq.

A thought on multi-tenant, maybe that shouldn't be in the OSS version. Otherwise feels like we are making it easy for somebody else to start offering SaaS.

from docq.

• add method to valid if a user belongs to an org
• add the selected org to the auth context.
• support per org admin vs super admins - move theis_admin column to the org_members (so admin status is set per org. Update the authenticate() method to set the admin session state correctly
• when the user login default to their personal org
• add DAL for Organisations
• partition user_groups table by org_id
• partition spaces table by org_id
• partiton space_groups table by org_id
• partition system setting by org_id
• partition user setting by org_id
• add Org management UI
  • [x]create and list orgs
• update add user UI to handle inviting existing users.
• update add user method to only allow admins to add to the currently selected org_id.
• update _get_path() to include the org id as the second segment. persistence should be an org subfolder within index, sqlite, and upload.
• system is the only sqlite file that should live outside an org folder.
• new users are added as a member to the current org in an SQL transaction
• users are unique across all orgs within a Docq instance. i.e. can be a member of one or more orgs. This will enable a large company to use org to segregate BU, departments where needed though this will reduce the power of Docq as spaces are not shared across orgs. In the future we may have to consider adding an explicit concept called tenant over orgs to further partition. This will mainly be required if SaaS in the main route so differing that for now.
• personal ask and upload are attached to a user not an org.
• super admins can create orgs but they aren't a member by default.
• org admins can create orgs and are added as a member (i.e default owner)

from docq.

@cwang thoughts: Should the personal chat be scoped to an org context or not associated with the org, rather associated directly to and only to a user?

I'm leaning towards the latter, associate with a user, no org context.

from docq.

Note: I decided not to go down the path of creating a default org for a user for now. I think that's warranted when self service sign up is implemented. Doing this would also require reworking the personal ask feature IMO otherwise it would be confusing. This MVP version assumes we'll (super admins) will set up orgs and create the initial user(s).

from docq.

@cwang thoughts: Should the personal chat be scoped to an org context or not associated with the org, rather associated directly to and only to a user?

I'm leaning towards the latter, associate with a user, no org context.

Two reasons why I'd vote for the former:

1. In an enterprise context (which this org feature mostly likely finds itself in), it's likely that personal chats are NOT personal as recent ChatGPT ban shows. I'd rather making a personal org which belongs to an individual, than making the exception here.
2. For simplicity, presumably it'd be a simple, blanket change if we don't make any exception about it?

from docq.

Note: I decided not to go down the path of creating a default org for a user for now. I think that's warranted when self service sign up is implemented. Doing this would also require reworking the personal ask feature IMO otherwise it would be confusing. This MVP version assumes we'll (super admins) will set up orgs and create the initial user(s).

That's absolutely fine for now. What's likely to happen is the system creates a personal org as the first org for self-service sign-ups. That could be done as part of SaaSifying effort

from docq.

For simplicity, presumably it'd be a simple, blanket change if we don't make any exception about it?

Changing personal chat to follow the same structure as Shared would make the API logic overall simpler in theory. But given it's presented differently (as a first class citizen) in the UI means we are probably only shifting things around with the overall complexity being the same.

from docq.

hold on - ah you are saying we should drop the personal chat as a first class citizen all together? If so, I'm not against that. I doesn make the whole UX simpler for the user.

from docq.

@cwang what was your original thinking when deciding to put all the chat-related data in the usage DB under personal? The need here is to have chat partitioned by user right?

from docq.

Not saying we drop it. What I'm saying is that personal != your own in any enterprise context and we shouldn't create loop hole that may go against ourselves :) If a user wants, they can create an entire personal org to do what they want in an isolated org.

Re the original design thinking for personal chat - yes, it was before the org. Have been suggesting refectoring the personal space disk file structure lately in anticipation for the org feature a few times.

from docq.