Sponsor and SponsorLevel models

[jace]

The sponsors of a project need to be acknowledged on the project page. While a fuller implementation is pending via Outreach, an interim implementation can help event teams operate fully off Hasgeek.com.

1. SponsorLevel defines the classifications of sponsors. It needs:
   • Title: the name of this level (Gold, Silver, etc)
   • Level: a number indicating the sponsorship level. Larger numbers indicate higher levels. (see comment) The number can be reused across SponsorLevel instances to indicate levels that have different titles but are equivalent
   • Sequence: disambiguation when two have the same level
2. Sponsor defines an individual sponsor. It needs:
   • State: draft, published, withdrawn invite (?), accepted, withdrawn
   • Title: the name of the sponsor
   • Logo URL: logo to show for this sponsor
   • Sequence: within the level, typically used to indicate order of commit
   • Description: a single line to display against the sponsor's name
   • Body: full page describing the sponsor, available at /<profile>/<project>/sponsors/<title-suuid>
   • Profile: link to Profile. The use case for this needs to be examined once profile pages are implemented (partially in Profile model should extend to user accounts #292)
3. SponsorMembership (pending on Membership models #401) grants a user administrative rights to the Sponsor model

To ensure uniformity in levels across projects, the platform should provide reference level numbers. This needs a specification (in addition to this ticket). Without standardisation, the sponsor record has the same limitation as labels of not being comparable across projects (discussed in #392).

[jace]

When a sponsorship is across projects, the Sponsor model must be created and updated individually in each project. Outreach has a Campaign model that refers to a specific deal. The Sponsor model can uplink to Outreach's Campaign model once Outreach is back in maintenance.

[jace]

Numeric levels will make it hard to design layouts, so maybe we can offer a limited list:

1. Exclusive (eg: Title)
2. Primary (eg: Platinum)
3. Secondary (eg: Gold)
4. Tertiary (eg: Silver)
5. Quaternary (eg: Bronze)
6. Partner Supporter (eg: Community, or Publicity Partner)

The SponsorLevel model can pick any of these six. It will need an additional sequence column to distinguish it from other SponsorLevel instances having the same level.

[jace]

Because Sponsor will link to Project and to SponsorLevel, which in turn links to Project, it needs a trigger to prevent cross parentage (#360).

[jace]

This model hierarchy is a bad idea because of the cross-parentage problem:

      Project
      /     \
     /       \
    /         \
Sponsor --- SponsorLevel

This one is bad UX because it forces defining sponsorship levels before adding sponsors:

Project
   |
   |
SponsorLevel
   |
   |
Sponsor

What we need is this:

      Project
      /     \
     /       \
    /         \
Sponsor     SponsorLevel

Sponsors can be added directly to the project at one of the six levels, and will be displayed using the default titles above ("Exclusive level", "Primary level", etc). Project owners can choose to customise the title by adding a SponsorLevel for each.

Optional: Titles can also be added directly to the Sponsor for when even more customisation is desired ("Radio Partner", "Press Partner", etc). This is risky as it may be used in place of the SponsorLevel, so maybe we should introduce it later.

[jace]

Revisiting this post-lockdown: sponsor levels are no longer relevant and can be dropped. The sponsor list can be flat, with a priority or sequence number, and displayed according to that.

The sponsor model will need some ideas borrowed from membership: invite, active, amend, revoked. However, they are not a regular membership type, as (a) they refer to a profile (presumably belonging to an organization, but not always), and (b) an invite must be accepted by a user on behalf of the profile. We can reuse the existing ImmutableMembershipMixin by forking it into ImmutableUserMembershipMixin and ImmutableProfileMembershipMixin.

[jace]

Resolved in #1106. UI for this feature will be a separate ticket.