Add default query mapping path to filter by COT tree def in QB search

[sharadsw]

Fixes #6098

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
• Add relevant documentation (Tester - Dev)
• Add a reverse migration if a migration is present in the PR

Testing instructions

• Create a new CO and set a COT
• Click the Search button next to the Determination QCBX
• Verify there is already a mapping line for filtering by COT tree def

[melton-jason]

Nice work!
Since the queryBuilderFieldPath overrides the field, this can probably be simplified by removing the queryBuilderFieldPath from the QueryComboBoxFilter type and instead allowing the field to be an Array of strings (MappingPath).

e.g., change

specify7/specifyweb/frontend/js_src/lib/components/SearchDialog/index.tsx

Line 44 in 0c9839d

readonly field: string & (keyof CommonFields | keyof SCHEMA['fields']);

to

readonly field: MappingPath | (string & (keyof CommonFields | keyof SCHEMA['fields']));

(And handling the case when field is an Array in toQueryFields)

[sharadsw]

@melton-jason The text search filter expects field to be a string as it seems to only work with simple fields and not mapping paths. I figured we need queryBuilderFieldPath for cases where the query builder needs a different path than what the search filter uses. (For taxon, the search filter filters by definition while the QB uses definition.id. Let me know if there's a better way to handle both cases at the same time

specify7/specifyweb/frontend/js_src/lib/components/SearchDialog/index.tsx

Lines 142 to 151 in 9cd74f2

	function testFilter<SCHEMA extends AnySchema>(
	resource: SpecifyResource<SCHEMA>,
	{
	operation,
	field,
	value,
	isNot,
	isRelationship,
	}: QueryComboBoxFilter<SCHEMA>
	): boolean {

[emenslin]

• Verify there is already a mapping line for filtering by COT tree def

Just want to check this is the correct behavior before approving but all ranks show up even if they are not part of the tree you are querying on. This isn't necessarily a problem but it could just potentially be confusing so I wanted to double check.

01-23-2025_10.07.mp4

[sharadsw]

@emenslin Yeah that is expected. The mapping line should ensure Taxon that don't belong to the COT don't show up in the results