De-link organizations and teams

[jace]

Lastuser's Organization and Team models are modelled on GitHub's. The assumptions are:

1. An Organization is a public-facing brand identity and has a username that shares namespace with User account. (There has been a discussion to merge these at the database level in Merge User, Organization and Team models into a new Principal model #91).
2. Organizations contain two or more Teams, Owners and Members (originally one, latter added with "Members" team #28), which cannot be deleted, and any number of user-added teams.
3. Teams are private to the Organization. Only members of the Organization can see the list of teams and membership of the individual teams. (Prior to "Members" team #28, any member of a team was considered a member of the organization. It is unclear if "Members" team #28 has resolved this appropriately since some notion of "membership" also exists in Flask-Lastuser.)

Under expected use circumstances, an average user will be a member of one organization, their employer, and maybe a few more representing non-profit causes or community groups.

With the benefit of hindsight of the past few years, we now know that (a) organizations are used to represent brandnames, so it's normal for an active user of HasGeek's infra (such as HasGeek staff) to be a part of ten or more organizations, and that (b) any changes to staff require adding or removing them from teams within each of these organizations, which is a pain. We've discussed having parent organizations (#6) as a means to centralise team management, with the caveat that the Owners and Members teams are special-cases that cannot be inherited, so those will instead be virtual teams, representing both their own members and inherited members.

Since #6 (and the related #34) represent tricky architecture – we may have a use case for parents of parents, making team membership lookups recursive – this issue presents an alternative proposal: de-link Team from Organization.

1. A Team can now be free-standing, having no associated Organization, while an Organization can still require an Owners and Members team to be specified (user selects from existing or makes new).
2. Since Team management rights are currently inherited from the Organization (you have to be in the org's Owners team), we will instead need membership flags that indicate administrative rights within the team.
3. As this is an incompatible change, Lastuser's API level 1 will need deprecation. Flask-Lastuser will need to be upgraded and all apps that currently use the Team model will be in limbo.
4. Writing an Alembic migration will be non-trivial. We will have to set the admin member flag based on whether the member is also present in the Owners team.

[jace]

Counterpoint: Teams are also useful for creating lists of individuals in which the maintainer of the list is not also a member of the list. Access rights to create such a list is currently granted via the organization's ownership.

If teams have no parent organization, the only way to have edit access to the team is by also being a member and having the appropriate membership flag (admin/owner) set. This makes it impossible to maintain a list of other people.

Why is this required? In #34 we wanted to promote a certain use case for teams up to the level of being an organization. The 2015 edition of The Fifth Elephant had an editorial panel comprised of non-HasGeek staff, but managed by a HasGeek staff member. If the team's membership was meant to be a statement of record on who was in the EP, it can't have a non-member (of the real-life entity) be a member of the team just for the sake of managing it. This brings up another scenario: sometimes the team is archived and membership is for the record, not for current activity, so it should be possible to "archive" a team, making it read-only -- or preventing a user from leaving a team by themselves, requiring the team's admin to do that instead.

[jace]

As an extension: Teams can optionally be owned by an Organization, allowing the team admin to then be present outside the team.

[jace]

We can make all this simpler by reversing the assumptions. Specifically:

1. Allow users to directly be members of organizations, without being a part of a team.
2. Remove the special case Members and Owners teams, converting those into roles (Introduce roles alongside permissions #118), but with roles being present on users rather than teams.
3. Allow optional teams (current functionality once Owners and Members are removed). Team members are not organization members unless they are also direct members, thereby allowing guests. This is also current functionality once the Members team becomes a Member role.
4. Optional: Allow teams to have roles in the organization. This is potentially problematic in that it introduces complexity with uncertain value. (With this, we reverse the original assumption in Introduce roles alongside permissions #118 that teams have roles, not individuals.)
5. Optional: Allow sub-organizations (Organizations should take a parent organization #6) where the sub-org inherits roles (and teams?) from the parent organization.

With this approach, organizations start out like teams with a simple list of members, but acquire complexity as needed.