Skip to content

Always set one is_lead related org in actions.project.edit.#5731

Open
mikerkelly wants to merge 6 commits intomainfrom
mikerkelly/project-action-edit-set-is-lead
Open

Always set one is_lead related org in actions.project.edit.#5731
mikerkelly wants to merge 6 commits intomainfrom
mikerkelly/project-action-edit-set-is-lead

Conversation

@mikerkelly
Copy link
Copy Markdown
Contributor

@mikerkelly mikerkelly commented Mar 26, 2026

Fixes #5699.

The create action sets is_lead on a related Org but the edit one did not. So if you changed the org, none would be lead. This fixes that by setting the first org passed in as lead, if none remain after the update.

I will move discussion about changing the relation to be an foreign key to a new issue.

We ought to set a lead organisation when we edit the project, but we don't. Add
lines illlustrating this.

The previous version of this test did happen to leave `org1` as lead, because
the `ProjectCollaboration` was not removed. So let's make the test use a
disjoint set of new orgs. Really there should be more tests.
Various parts of the application do or may assume that there is at least one
`org` marked as `is_lead` through `ProjectCollaboration`, per project. So we
should ensure that that happens in the edit action. For now, just pick the
first that the form provides and set it. This can lead to issues if there was
already a lead org set but a different org is passed in first. It happens that
right now that cannot happen, as the form only allows one organisation to be
set, but we should improve this further.

I have left detail in comments as this part of the codebase needs work and has
some surprising properties.
Perhaps surprisingly, the lead org can be changed when two orgs are passed in,
one of them already being lead org, depending on ordering. This test shows that
and will make a future commit that changes this clearer.

The behaviour seems a bit too different to parametrise.
For now, this seems the safest thing to do, ensuring that this function always
sets a lead org, but does not overwrite it if it was already related, and still
is after. This is being defensive against future change, as for now the form
can only pass one anyway.
We can create multiple objects in one line, which is briefer and easier to read.

`assert_only_lead_org` makes it easier to read what is being asserted about the
`ProjectCollaboration` instances.
@mikerkelly mikerkelly force-pushed the mikerkelly/project-action-edit-set-is-lead branch from 2f8044e to ff84435 Compare March 26, 2026 09:28
This makes the label made by the factory include the same number as the
variable name number, which is easier to parse when looking at fails or the
debugger.
@mikerkelly mikerkelly force-pushed the mikerkelly/project-action-edit-set-is-lead branch from ff84435 to 26c4de2 Compare March 26, 2026 09:29
@mikerkelly mikerkelly marked this pull request as ready for review March 26, 2026 11:41
assert not Project.objects.exists()


def assert_only_lead_org(project, org):
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice refactor!

Copy link
Copy Markdown
Contributor

@nishtha-kalra nishtha-kalra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will move discussion about changing the relation to be an foreign key to a new issue.

This PR looks good. I liked the idea that we can make the relation as a foreign key. Could you link the issue to this PR whenever you create it or link this PR to the issue? That way we can always refer this PR whenever someone picks up the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Set a lead org for each project

2 participants