Skip to content

Conversation

@asinn134
Copy link
Collaborator

@asinn134 asinn134 commented Feb 3, 2026

Objective

MDS-6771

-The fix for this ended up to be pretty small. For the mine in production it has the mine manager Mike Allen as a record in the mine_party_appt table and that has deleted_ind = True, this record also does not have an end_date.

The problem is then with the retrieval of the mine_manager done in the mine.py file the conditions for choosing which mine manager to return are in part depending on an end_date and because Mike Allen's record has no end date it actually ends up passing all the conditions, and the retrieval of the mine manager returns the first record that passes all the conditions. We end up seeing Alex Mcleod as a recipient of the email which is fine since he is the submitter, and we also then see Mike Allen as a recipient too and that is because Mike Allen is the record that ends up being returned first when retrieving the mine manager thereby taking the place of the actual current mine manager David Baines.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Feb 3, 2026

@asinn134 asinn134 merged commit 0bc176c into develop Feb 4, 2026
13 checks passed
@asinn134 asinn134 deleted the mds-6771-previous-mine-manager-receiving-email-error branch February 4, 2026 19:10
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.

3 participants