Add Organization and OrganizationRole models to studio

[yasinelmi]

Closes #5962

Summary

Added two new models for organizational structure and role-based access management.

Organization Model

Represents organizations that manage channels

Fields: id (UUID), name, description, thumbnail, thumbnail_encoding, public, deleted; timestamps created_at, updated_at; uses CustomManager().
Channel ownership is canonical via Channel.organization FK (not org→channel).

OrganizationRole Model (Through Model)

Links User ↔ Organization and stores membership metadata.

Fields: id (UUID), user FK, organization FK, role, description, status (uses organization_role_status_choices, default pending), joined_at, updated_at, invitation_accepted_at, invited_by FK.

Methods: accept_invitation(), decline_invitation().

DB constraints: unique_together = ('user', 'organization') and index on (organization, status).

AI usage

Used AI to generate models but they were carefully reviewed

[learning-equality-bot]

👋 Hi @yasinelmi, thanks for contributing!

For the review process to begin, please verify that the following is satisfied:

• Contribution is aligned with our contributing guidelines

• Pull request description has correctly filled AI usage section & follows our AI guidance:

  AI guidance

  
  

  State explicitly whether you didn't use or used AI & how.

  If you used it, ensure that the PR is aligned with Using AI as well as our DEEP framework. DEEP asks you:

  • Disclose — Be open about when you've used AI for support.
  • Engage critically — Question what is generated. Review code for correctness and unnecessary complexity.
  • Edit — Review and refine AI output. Remove unnecessary code and verify it still works after your edits.
  • Process sharing — Explain how you used the AI so others can learn.

  
  

  Examples of good disclosures:

  "I used Claude Code to implement the component, prompting it to follow the pattern in ComponentX. I reviewed the generated code, removed unnecessary error handling, and verified the tests pass."

  "I brainstormed the approach with Gemini, then had it write failing tests for the feature. After reviewing the tests, I used Claude Code to generate the implementation. I refactored the output to reduce verbosity and ran the full test suite."

Also check that issue requirements are satisfied & you ran pre-commit locally.

Pull requests that don't follow the guidelines will be closed.

Reviewer assignment can take up to 2 weeks.

[bjester]

Overall, the foundational pieces are present, but I have some questions on the use cases of some fields. My requested changes are mostly around indices, but I think the area most in need of attention is the invitation architecture. The implementation would have benefited some planning on what that looked like, for example a Github issue/spec written up first. It feels like a really good idea to reuse the existing Invitation structure as much as possible, and without significant details in the PR description, I'm not able to gauge on what the decisions and motivations were for the current implementation.

[ArthurMousatov]

Overall, the foundational pieces are present, but I have some questions on the use cases of some fields. My requested changes are mostly around indices, but I think the area most in need of attention is the invitation architecture. The implementation would have benefited some planning on what that looked like, for example a Github issue/spec written up first. It feels like a really good idea to reuse the existing Invitation structure as much as possible, and without significant details in the PR description, I'm not able to gauge on what the decisions and motivations were for the current implementation.

Thanks for the thorough review - we'll modify the models according to your comments. We'll strip out some properties/indexes from the models, and fix the inter-model relationships:

• A few of the relationships were erroneous - channels and organizations have a one to many relationship, so the channel model will have an organization foreign key instead.
• The "superuser" for an organization has been stripped. Instead, it feels better to have one "owning" role (admin) that multiple users can have to avoid issues with owners leaving organizations. And, even if we do go ahead with an "owner" role, it would still be beneficial to use the same organization role model.

As for the invitation model, we'll take definitely look at re-using the invitation structure as per your recommendation. However, would it be a necessary addition to this PR? As it stands, this PR will not impact any current functionality.

[marcellamaki]

hi @ArthurMousatov and @yasinelmi !

However, would it be a necessary addition to this PR?

Let's just remove any invitation work from this PR entirely, and focus on the other models for now. Then, in a follow up PR, you can add in the invitation integration to match.

(The alternative would be that we merge this with the changes made here, but then address this in a follow up issue as a next task. But it seems a bit roundabout to implement and then just immediately change it.) Either way, aligning it sooner rather than later will prevent future headaches and duplication.

Thank you!