More details on moving organizations

Author: stsewd

docs/development/design/organizations.rst

@@ -8,8 +8,8 @@ we only support individual accounts.
 Several integrations that we support have organizations,
 where users group their repositories.
 
-Why support organizations in the community site?
-------------------------------------------------
+Why move organizations in the community site?
+---------------------------------------------
 
 We support organizations in the commercial site,
 having no organizations in the community site makes the code maintenance difficult.
@@ -20,39 +20,22 @@ Users from the community site can have organizations in external sites from wher
 Currently users have all projects from different organizations in their account.
 Having not a clear way to group/separate those.
 
+There is also a product decision.
+Supporting organizations only on code,
+but enable the feature only on the commercial site.
+
 How are we going to support organizations?
 ------------------------------------------
 
-Currently users can have several projects.
-With organizations we have two paths:
-
-#. Support users and organizations to own projects
-#. Support only organizations to own projects
-
-With 1, the migration process would be straightforward for the community site.
-With 2, the migration process would be straightforward for the commercial site.
-
-How to migrate current projects
--------------------------------
-
-If we choose to go with the second option from :ref:`development/design/organizations:How are we going to support organizations?`
-we'll need to define a migration plan,
-like creating an organization for all current projects.
+Currently only users can own projects.
+With organizations this is going to change to: 
+Users and organizations can own projects.
 
-But, for whatever option we choose,
-we'll need to move the models defined in the corporate site
-to the community site.
+With this, the migration process would be straightforward for the community site.
 
-From the technical site
-~~~~~~~~~~~~~~~~~~~~~~~
-
-We should start by removing unused features and dead code from the organizations in the corporate site,
-and isolate/separate the models to be moved from the ones that aren't going to be moved.
-After that, it should be more easy to move the organizations *app* (or part of it)
-to the community site (and not changes in table names would be required).
-
-Additionally, we are going to need to edit the current querysets, modify/add UI elements,
-and add new endpoints to the API (v3 only).
+For the commercial site we still have a decision.
+Are we going to support users and organizations to own projects?
+Or just organizations?
 
 What features of organizations are we going to support?
 -------------------------------------------------------
@@ -77,6 +60,68 @@ So, we should only support admin permissions for teams.
 Subscriptions, this is only valid for the corporate site,
 since we don't charge for use in the community site.
 
+How to migrate current projects
+-------------------------------
+
+Since we are not replacing the current implementation,
+we don't need to migrate current projects from the community site nor from the corporate site.
+
+How to migrate the organizations app
+------------------------------------
+
+The migration can be split in:
+
+#. Remove/simplify code from the migrations app on the corporate site.
+#. Isolate/separate models and code that isn't going to be moved.
+#. Start by moving the models, managers, and figure out how to handle migrations.
+#. Move the rest of the code as needed.
+#. Activate organizations app on the community site.
+#. Integrate the code from the community site to the new code.
+
+We should start by removing unused features and dead code from the organizations in the corporate site,
+and simplify existing code if possible (some of this was already done).
+
+Isolate/separate the models to be moved from the ones that aren't going to be moved.
+We should move the models that aren't going to me moved to another app.
+
+- Plan
+- PlanFeature
+- Subscription
+
+This app can be named *subscriptions*.
+We can get around the table names and migrations by setting the explicitly the table name to `organizations_<model>`,
+and doing a fake migration.
+Following suggestions in https://stackoverflow.com/questions/48860227/moving-multiple-models-from-one-django-app-to-another.
+Code related to subscriptions should be moved out from the organizations app.
+
+After that, it should be more easy to move the organizations *app* (or part of it)
+to the community site (and not changes in table names would be required).
+
+We start by moving the models.
+
+- Organization
+- OrganizationOwner
+- Team
+- TeamInvite
+- TeamMember
+
+Migrations aren't moved, since all current migrations depend on other models that aren't
+going to be moved.
+In the community site we run an initial migration,
+for the corporate site we run a fake migration.
+
+For managers and querysets that depend on subscriptions,
+we can use our pattern to make overridable classes (inheriting from ``SettingsOverrideObject``).
+
+Templates, urls, views, forms, notifications, signals, tasks can be moved later
+(we just need to make use from the models from the `readthedocs.organizations` module).
+
+If we decide to integrate organizations in the community site,
+we can enable the app.
+
+After the app is moved,
+we can move more code that depends on organizations to the community site.
+
 Namespace
 ---------
 
@@ -90,3 +135,11 @@ And most of the users don't have a custom domain.
 We could keep the current behavior for the community site and use `organization.slug` + `project.slug` for the corporate site,
 since in the corporate site we don't care so much about a unique namespace between all users, but a unique namespace per organization.
 We can refactor the way we get the namespace to be more easy to manage in both sites.
+
+Future Changes
+--------------
+
+Changes that aren't needed immediately after the migration,
+but that should be done:
+
+Edit the current querysets, modify/add UI elements, and add new endpoints to the API (v3 only).