Labels

[jace]

The Section model is a bit crude in that (a) sections must be re-defined for every project, and (b) each proposal can have only one section. Project owners may want more fine-grained control. Enter labels:

1. Profile can have zero or more Labelset instances attached to it. A labelset contains labels and operates in either checkbox mode (select any number) or radio mode (select one)
2. Project can have zero or more labelsets enabled for that particular project. These labels now appear in the UI.
3. Label instances are attached to Labelset (parent) and to Proposal in many-to-many relationships.

Existing sections can be migrated to labelsets and enabled for each project. Some code for this is already in Funnel in models/labels.py via commit a4477f2.

Simplified proposal

1. A label model defines a piece of text and an optional colour code.
2. Proposals and labels have a many-to-many relationship.
3. Labels may have sub-labels. When this happens, only one of the sub-labels can be applied to a Proposal.
4. Labels can be parented by Project or Profile (making them available across all projects), or may be free standing, making them universal across all profiles. For the sake of simplicity, we may limit ourselves to Project, or to just Project and Profile.

[jace]

Also consider emoji icons for labels (instead of, or in addition to colour codes).

[jace]

Labels should be restricted to projects. Since workflows change often, old projects shouldn't be affected when labels are changed. Instead, new projects can be cloned from old projects so that the labels defined there are inherited.

[jace]

More complications for labels:

1. Some labels are public. Anyone can self-declare their talk to be a crisp talk or a full talk, beginner or intermediate level.

2. Some labels are restricted. Only an editor can label a talk as shortlisted.

3. Some labels are private (optional). A label tagging a talk as suspicious shouldn't be visible to anyone outside editorial.

4. Once a proposal has been reviewed, the proposer shouldn't be allowed to change labels. Proposals should have a locked_labels flag restricting edits by the proposer.

[iambibhas]

Proposed Models

Label

• project
• name - needed?
• title - to show on labels
• labelset - the group it belongs to, nullable
• restricted - only reviewers/admins can apply this labelset to a proposal
• public - whether the label is public once it’s set
• uuid

LabelSet

• name - needed?
• title - to show on labels
• project - the project this label is linked to
• radio_mode - whether it’s a radio type or checkbox type set
• mandatory - as it says
• restricted - only reviewers/admins can apply this labelset to a proposal
• public - whether the label is public once it’s set
• uuid

ProposalLabel

• project
• proposal
• label
• created_at/updated_at

While creating ProposalLabel record,

• Check if label belongs to a labelset
  • if not, it’s standalone
    • Check if it’s already set for the same project and proposal,
      • if yes, update
      • if no, create record
  • if yes, it belongs to a labelset
    • Check if the labelset is in radio_mode
      • if yes, create/update
      • if no, create/delete differences
    • Check if labelset is mandatory and value is not provided
• when a proposal is moved to a different project,
  • remove all labels from existing project,
  • go to proposal edit page for new project so that mandatory labelsets can be assigned
• when a new project clones labels from old project
  • copy proposallabel and proposallabelsets to new project
• Use current_access() to restrict assigning, creating and deleting of labels if possible. Because those functions will also depend on the labelset config in db, probably should define them in model methods to handle the validations as well.
• The forms to create/delete/assign labels have to be generated from db records

[jace]

The Proposal prefix is incorrect. Labels belong to projects first. We don't need the Project prefix either because it's not used anywhere else. We don't have a ProjectProposal or ProjectVenue.

[jace]

Implementation is in #392. Discussion can move there.