Currently, users who implement a custom TypeSearches file within App Resources face a challenge when new type search tables or fields are introduced. This manual update requirement not only adds extra workload but also creates inconsistencies in user experience, particularly when new schema expansions occur.

A major problem here is that the TypeSearches app resource (see https://github.com/specify/specify7/commits/production/config/backstop/typesearch_def.xml) is almost always custom defined in databases that have used Specify 6 since customizing the fields searched in a query combo box update this file. Once customized, Specify looks at this custom resource rather than the system one.

This leaves users with custom TypeSearches unable to use the query combo box for things like Collection Object Groups, Tectonic Units, or any new tables/fields that we add in the future. The only workaround is for users to click on the 🔍 (search) icon next to the query combo box to search manually for records.

Problem Statement

When new fields are added to the system, such as the recent addition of geo-related fields, users with a custom TypeSearches file must manually update their configurations to ensure that new fields, including cojo and taxonTreeDef, are searchable. This is particularly problematic for users who expect seamless integration and functionality with the system's default search capabilities.

Current Limitations:

• Users with a custom TypeSearches file do not automatically receive updates or expansions related to default type searches.
• Specifically affected tables include:
  • collection
  • specifyuser
  • institution
  • collectionobjectgroup
  • collectionobjectgrouptype
  • tectonicunit

Proposed Solution

Implement a logic that automatically fills in the gaps of custom TypeSearches files with the system's default settings. This would ensure that any new fields or tables added to the system are automatically integrated into the user's search capabilities without requiring manual intervention.

This proposal does not involve updating the custom XML, rather just allowing Specify to "fall back" on a system default rather than looking only at the custom definition for every table.

Benefits:

• Enhanced User Experience: Users will benefit from seamless access to new fields without needing to update their custom configurations.
• Reduced Maintenance: This would significantly decrease the maintenance burden on admin users who regularly need to update their TypeSearches files to be able to use basic functions of the app.
• Consistency Across Systems: Ensures that all users, regardless of their custom configurations, have access to the same search capabilities and functionalities.

Discussed in #6232