Set default cotype on the frontend

[sharadsw]

Fixes #5223

Checklist

• Self-review the PR after opening it to make sure the changes look good
  and self-explanatory (or properly documented)
• Add automated tests
• Add relevant issue to release milestone

Testing instructions

• Go to Data Entry -> Collection Object
• Verify the default CoType on the form is same as the Collection's CoType

[sharadsw]

Hmm, this breaks a couple of resource api tests which doesn't sound good

specify7/specifyweb/frontend/js_src/lib/components/DataModel/__tests__/resourceApi.test.ts

Lines 201 to 219 in 1419cd7

	describe('needsSaved', () => {
	test('changing field makes needsSaved true', () => {
	const resource = new tables.CollectionObject.Resource({
	id: collectionObjectId,
	});
	expect(resource.needsSaved).toBe(false);
	resource.set('text1', 'a');
	expect(resource.needsSaved).toBe(true);
	});
	test('changing dependent relationship makes needsSaved true', () => {
	const resource = new tables.CollectionObject.Resource({
	id: collectionObjectId,
	});
	expect(resource.needsSaved).toBe(false);
	resource.set('determinations', []);
	expect(resource.needsSaved).toBe(true);
	});
	});

[sharadsw]

Had to do some workarounds here to get the tests working. Lots of tests involving CO don't have a linked CollectionObjectType or a linked Collection -> CollectionObjectType. Some tests used data from static test files, which I have updated to include Collection/Cotype.

Let me know if there's a better way to do any of these.

[emenslin]

Testing instructions

• Go to Data Entry -> Collection Object
• Verify the default CoType on the form is same as the Collection's CoType

This does work but I am a little confused about the query behavior. When querying with cot as the base table it works as I expect showing the 2 cot I made in this collection, but when querying with collection as the base table cot is formatted and only shows the default. Since we added the ability to create multiple cot shouldn't it be aggregated when collection is the base table?

Querying on collection:

Querying on cot:

[pashiav]

Testing instructions

• Go to Data Entry -> Collection Object
• Verify the default CoType on the form is same as the Collection's CoType

I have the same concerns as #5224 (review), but it works!

[sharadsw]

@emenslin That does look strange. I think it's happening because each collection record in the db gets linked to only one collectionObjectType (the default one) and so using collection as the base table only shows the defaults. Not sure if that can be changed unless we change the schema

[grantfitzsimmons]

@emenslin That does look strange. I think it's happening because each collection record in the db gets linked to only one collectionObjectType (the default one) and so using collection as the base table only shows the defaults. Not sure if that can be changed unless we change the schema

The issue is that the schema caption for the default COT relationship field should clarify this. Currently, it appears ambiguous, suggesting there is only one COT in the collection.

[melton-jason]

@emenslin That does look strange. I think it's happening because each collection record in the db gets linked to only one collectionObjectType (the default one) and so using collection as the base table only shows the defaults. Not sure if that can be changed unless we change the schema

The issue is that the schema caption for the default COT relationship field should clarify this. Currently, it appears ambiguous, suggesting there is only one COT in the collection.

Yep, if I remember correctly the Collection -> CollectionObjectType relationship is only to denote the default collection object type for the Collection.
Multiple CollectionObjectTypes can exist in a single Collection, but there can only be one default.

[sharadsw]

I agree that the schema caption could be clearer. We can make that change as a part of #5290

[melton-jason]

This implementation works, but maybe it would be worth changing businessrules a little (in this case specifcially for customInit rules) so we can await businessRuleManager.pendingPromise instead of await new Promise(process.nextTick) in tests.

Also, maybe it'd be worth just including the Collection -> CollectionObjectType in a domain context call so we can synchronously access the collection's default CollectionObjectType wherever the schema has already been fetched.
This would save a lot of calls to the backend, and be significantly faster from the user's perspective.

More information in my comments!

[melton-jason]

Looks good! Take a look at my recent changes.
Instead of just returning the ID of the CollectionObjectType in the /context/domain.json endpoint, I thought it might be easier if we just directly format it as the the api uri.

I updated the static /context/domain.json endpoint for the frontend tests to include the defaultCollectionObjectType property.
I also realized we weren't using a LOT of the static files in the */tests/fixtures/ directory, so I removed all the files which are unused.

[emenslin]

Testing instructions

• Go to Data Entry -> Collection Object
• Verify the default CoType on the form is same as the Collection's CoType

Looks good!

fixed