Support Default TypeSearches Alongside Custom Configurations

[grantfitzsimmons]

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.

Current Workaround

As a stop gap measure for 7.10, you can update the XML for your TypeSearches app resource with the following lines between the <typesearches> element in the resource:

    <typesearch tableid="1016"   name="CollectionObjectGroup" searchfield="name" displaycols="name"    format="%s"     dataobjformatter=""/>
    <typesearch tableid="1018"   name="CollectionObjectGroupType" searchfield="name" displaycols="name"    format="%s"     dataobjformatter=""/>
    <typesearch tableid="23"  name="Collection"             searchfield="collectionName" displaycols="collectionName" format="%s"  dataobjformatter=""/>
    <typesearch tableid="94"  name="Institution"            searchfield="name"            displaycols="name"               format="%s"     dataobjformatter=""/>
    <typesearch tableid="72"  name="SpecifyUser"            searchfield="name"            displaycols="name"           format="%s"     dataobjformatter=""/>
    <typesearch tableid="1027"  name="TectonicUnit"         searchfield="fullName"        displaycols="fullName"           format="%s"     dataobjformatter="TectonicUnit"/>
    <typesearch tableid="1026"  name="TectonicUnitTreeDefItem"       searchfield="name"   displaycols="name"               format="%s"     dataobjformatter=""/>

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

^{Originally posted by bronwyncombs February 12, 2025}
Currently, a custom TypeSearches file in App Resources overrides system defaults. This poses an inconvenience when new typeSearch tables/fields are added since the App Resource must be updated to make new qcbx fields searchable.

It would be much better for the users if there was logic to fill in the gaps of custom TypeSearches files with the system defaults. This is especially beneficial when the schema is expanded and users expect new forms/fields to behave with the system's default search abilities.

The addition of geo, for example, means databases with a TypeSearches file will need to manually configure this for the cojo and taxonTreeDef fields qcbx search to work.

[grantfitzsimmons]

@specify/ux-testing Are there other thoughts on this issue?

I find this to be very important considering primarily because users in a database with a custom TypeSearches app resource cannot search for COGs, COGTs, Specify Users, and more using a query combo box.

Most customized databases have this app resource as customizing a query combo box in 6 automatically created a copy of this resource.

[lexiclevenger]

I ran into this on kufish with specify user. I agree that this is important to fix because it will impact the user's ability to use the new features on a large number of databases.

[combs-a]

Yes, 100%. It's quite annoying to have to go into the search rather than get to type into the field, since it takes quite a bit longer in comparison. I've run into this with all the tables you've mentioned (COGs, COGTs, Sp Users) on sdnhmherps.

Considering we already have default fallbacks for custom forms, I don't see why this shouldn't be the same.

[grantfitzsimmons]

@combs-a Do you have similarly strong thoughts on #6243 ?

[combs-a]

@grantfitzsimmons I think it'd be a great update to have a default DataObjFormatter file as well. It's not as frustrating as this issue since technically you can still add something via search still, but it's not great.