Default COTypes are not always being set

[emenslin]

Describe the bug
In some dbs the default COT is not set for all the collections. This is in ojsmnh and geodefaults where no migrations are failing and is potentially in other dbs.

To Reproduce
Steps to reproduce the behavior:

1. Go to ojsmnh
2. Use the 'COT query'
3. See that not all collections have a COT

OR:

1. Go to geodefaults
2. Query on collection
3. Add COT -> name
4. See it is blank

(can also check other dbs but it is not on every db)

Expected behavior
Defaut COT should be automatically set for every collection in a db.

Screenshots

Please fill out the following information manually:

• OS: Windows 11
• Browser: Chrome
• Specify 7 Version: production
• Database Name: ojsmnh, geodefaults
• Collection name: fossil invertebrates
• User Name: spadmin
• URL: https://ojsmnh20241003wb-production.test.specifysystems.org/specify/query/244/

[grantfitzsimmons]

From October 2nd, 2024 in the #development-meetings Slack channel:

The CollectionObjectTypeID was not set by the 7.9.7 migration in cases where there are multiple collections in a single discipline. This explains the issue that UBC had with creating new determinations.

It looks like we might need to do a new migration to solve this when cases like this have occurred, but maybe this is due to another factor we haven't considered. This migration is included in https://github.com/specify/specify7/blob/2a0b516e3e249816a90fb0c196875670ca41cbf0/specifyweb/specify/migrations/0002_geo.py#L65-L69|0002_geo.py but I'm not clear why it failed in this case.

Screenshot in DBeaver is beaty on the CA server.
See hujinnhc on the test panel and it worked just fine. Maybe this was fixed manually?

Slack Message