Create a new component table for CO children

[CarolineDenis]

Fixes #6708

Warning

This PR affects database migrations. See migration testing instructions.

Checklist

• Self-review the PR after opening it to make sure the changes look good and
  self-explanatory (or properly documented)
• Add relevant issue to release milestone
• Add pr to documentation list
• Add a reverse migration if a migration is present in the PR

Testing instructions

1. Initial Setup

• In your Collection Object (CO) view definition, above the determination subview, add the following snippet:

<row>
  <cell type="subview" viewname="Component" id="6" name="components" colspan="14"/>
</row>

• Add a new Component view definition using the default provided in the list.
• Verify that a default view definition for Component is available.
• In Collection Preferences, add the following entry:

"catalogNumberParentInheritance": {
  "behavior": {
    "inheritance": true
  }
}

2. Schema Configuration

• Open the Component schema configuration.
• Verify the schema config loads successfully.
• Verify that the relationship type field is set to use the CollectionObjectType pick list by default.

3. Data Entry: Component with its Own Catalog Number

• Open a new Collection Object (CO) form.
• Verify the Component subview is visible.
• Add a new Component with a custom catalog number.
• Save the form.
• Verify the Component is created and the catalog number appears as expected.

4. Data Entry: Component with Catalog Number Inherited from CO

• Remove the catalog number from the Component.
• Save the form.
• Reload the page.
• Verify the catalog number from the parent CO appears grayed out in the Component’s catalog number field.

5. Assigning Taxon Name to Component

• In the Component form, enter a taxon name in the name field (this field corresponds to the taxon).
• Begin typing a name and confirm that suggestions appear from the taxonomic tree associated with the selected Component type.
• Save the form.
• Verify the taxon name is saved and displayed correctly on the Component form.

6. Autocomplete Filtering by Type

• Try entering a taxon name from a different tree than the one linked to the selected Component type.
• Verify that the name does not appear in the suggestions.

7. Validation on Mismatched Type and Name Trees

• Verify your Component has a valid type-name pair from the same tree, and save the form.
• Change the Component type to one that belongs to a different taxonomic tree than the assigned name.
• Verify a validation error or save blocker is displayed.

8. Query Builder: Component Search

• Open Query Builder and search for a Component you created.
• Verify it appears in the results.

9. Query Builder: Component with Inherited Catalog Number

• Search for a Component without its own catalog number.
• Use a filter for catalog number = [parent CO's catalog number].
• Verify the Component is returned in the results.

10. Workbench: Component Table as Base

• Create a new Workbench plan with Component as the base table.
• Verify you can create and save a new Component using the Workbench.
• Verify you can Add a new Component to an existing CO.

11. Workbench: CO Table as Base

• Create a new Workbench plan with Collection Object (CO) as the base table.
• Add columns for:
  CO catalog number
  Component
• Verify you can Create a new CO with a new Component child.

[grantfitzsimmons]

@CarolineDenis

==> No we should create one; it's a good idea, should we do it as well for primary CO in a COG?

Definitely! Anytime catalog number is inherited

[melton-jason]

Not an Issue with this PR, just a quick note here for main in general: I had been very consistently receiving the following error when applying the specify/0036_remove_spquery_selectseries migration when testing the branch with a database from v7.11.0:

django.db.utils.OperationalError: (1091, "Can't DROP COLUMN SelectSeries; check that it exists")

I tracked down the cause of the consistent migration error, and right now it will happen on any database moving from v7.11.0+ to main (soon to be v7.11.1).

Specifically, the error is completely correct: the SelectSeries column is always already removed from these databases.

The specify/0036_remove_spquery_selectseries.py already exists as specify/0032_remove_spquery_selectseries in v7.11.0+:

v7.11.0.1, specify/0032_remove_spquery_selectseries.py

specify7/specifyweb/specify/migrations/0032_remove_spquery_selectseries.py

Lines 6 to 17 in 4c3ccc4

	class Migration(migrations.Migration):
	dependencies = [
	('specify', '0031_add_default_for_selectseries'),
	]
	operations = [
	migrations.RemoveField(
	model_name='spquery',
	name='selectseries',
	),
	]

When the changes in v711-prerelease were merged back into main, there already existed a specify/0032 migration so the select series migration was renamed to what it is now: specify/0036_remove_spquery_selectseries.

The change was introduced in 9bf24fa; PR #6885.

The result is that whenever someone goes from 7.11.0+ and has already applied specify/0032_remove_spquery_selectseries, the error will be encountered when attempting to apply specify/0036_remove_spquery_selectseries.

[melton-jason]

Good work so far! 🥳

This is still only a partial review (I'm still reviewing the rest!), but I will submit this review so the points can be addressed/discussed whilst I wrap up looking over the rest of the code/tests.

[melton-jason]

Nice work on the frontend changes! It's coming together 👏

This review covers what is left of the backend from #6721 (review).

Most of the comments are related to the migration itself, but there are a few comments for other parts as well.

---

I do also have some questions regarding the catalogNumberParentInheritance Collection Preference.

What is the preference trying to accomplish and why is it needed? I could not easily find where the requirements for the preference are. If you know where they are, could you provide a link or summary in a comment or the PR description?

Primarily my question is that: instead of showing the parent catalogNumber as a placeholder (and keeping the Component -> catalogNumber as empty/null) and modifying queries using Component -> catalogNumber -> Equal, what is the issue with literally inheriting the parent's catalogNumber? So whenever a Component is added to a CollectionObject, the Component's catalogNumber would be set to the CollectionObject's¹.
That way, we would not need to modify any query behind the scenes, and a user constructing a query could leverage all of the other filters (IN, LIKE, CONTAINS, etc.).
Currently, there is nothing wrong with having Components with duplicate catalogNumbers (if there is, we should provide a default Uniqueness Rule).

If we are keeping the current placeholder solution, could we at least show the placeholder for new Components as well? It might be confusing that there is a difference for new/existing Components.

Screen.Recording.2025-07-16.at.12.41.29.PM.mov

---

Some other general comments:

• Are we providing other defaults for Components? Things like:
  • Record Formatter
  • Record Aggregator
  • TypeSearch
  • Field Format (for CatalogNumber field?)
  • Uniqueness Rules
• I would love to see a visual editor for Collection Preferences! Even if Statistics preferences wouldn't yet be included, just for these and other simple preferences.
  Even with instruction, manually editing a busy non-formatted JSON file is intimidating and prone to error

Footnotes

1. we would need to delay doing so for new COs which are auto-incremented, at least until the CO is saved and then we can set the Components catalogNumber ↩

[grantfitzsimmons]

@CarolineDenis After reviewing some more, we are missing a critical field which I did not consider previously – determiner, which is necessary to say who decided a component was of a particular taxonomy. Can this be added? The original requirements have already been updated.