Why are we doing this?

• is_lead is not being set on the orgs when it is updated in the staff area
• orgs is a ManyToManyField (source) - but we only ever show one in the UI, so set is_lead on the one we want to show (source)

We should make sure we either only set one org per project, or we always set a lead org when changing orgs on a project. A database check constraint cannot enforce "exactly one of these", so we will have to rely on the actions.projects.edit business logic to enforce this, for now.

Alternatively, now or later, make lead_org a foreign key, not picking from among the is_lead organisation from the orgs ManyToManyField. The primary organisation is semantically different enough to warrant its own foreign key. There are no projects in production that have more than one organisation right now. This keeps causing pain. Fixing the data model would make many parts of the application simpler and more consistent. It would be more work now, but may save it in the long run. This was added in #2827 and #3571 speculatively in case we wanted to represent more than one organisation collaborating on a project, without any use of it since then. If we do want to represent this in future, I think a better representation would be to use one foreign key for the main organisation and a many-to-many relation for collaborators. That reflects the reality that all projects have a main organisation, and the UI that wants to centre that organisation. We can just do the foreign key part now, leaving orgs in place.

How will we know when it's done?

When each project only has one org, or only has one lead org.

What are we doing?

• Set is_lead in Projects.actions.edit after call to orgs.set. Always set one is_lead related org in actions.project.edit. #5731
• fix actions.project.edit. It is currently mixing concerns by using form methods in a confusing way. Instead it should completely bypass the form.save, decoupling the action from the form.
  • We recently changed this form and maybe that has silently broken this code in other ways, but it is hard to reason about.
• make ProjectEdit view use the project edit action in the public site, so we consistently use the same code path (though for now as that only updates status and status description, there are no relevant side effects, that may not be true in future).

(Optional, new issue?) If we do the foreign key approach:

• PR to make lead_org a primary key
  • add Project.lead_org as a nullable ForeignKey (more easily searchable than org).
  • set it on create / edit
  • migration populating it from the first (and only) org in orgs
  • make it non-nullable
• PR to update all UI and code to use the lead_org, not orgs. This can be many commits.
• Optionally later we can remove Project.orgs, though probably not needed if there is any chance we want to represent and use colloborating organisations any time soon, as it can be a start for that.

Defining delivery tasks guidance

Linked content

• Bug report: Organisation URL and logo not displayed on project detail page after edit #5614
• Return the first org if lead org doesn't exist #5697