Support Default DataObjFormatters Alongside Custom Configurations

[grantfitzsimmons]

Currently, users who implement a custom DataObjFormatters file within App Resources face a challenge when new tables are introduced.
It requires a manual update which not only adds extra workload but also creates inconsistencies in user experience, particularly when new schema expansions occur, but also leaves our team unable to update defaults when they need to change.

A major problem here is that the DataObjFormatters app resource (see https://github.com/specify/specify7/blob/production/config/backstop/dataobj_formatters.xml) is nearly always custom defined in databases since it is nearly always necessary to edit the table formats and aggregation for how data fields appear on labels, queries, and exports.
Once customized, Specify looks at this custom resource rather than the system one.

This leaves users with custom DataObjFormatters unable to use the query combo box, query builder, and other query mechanisms to display things like the Collection Object Group (formatted), COG children (aggregated), Tectonic Unit (formatted), Collection Object Type (formatted), 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 and search specific fields from there.

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 DataObjFormatters file (almost every collection) will not automatically receive updates or expansions related to default table formats and aggregation.
• Specifically affected tables include:
  • specifyuser
  • collectionobjectgroup
  • collectionobjecttype
  • collectionobjectgrouptype
  • tectonicunit
  • tectonicunittreedef
  • tectonicunittreedefitem

Proposed Solution

Implement a logic that automatically fills in the gaps of custom DataObjFormatters files with the system's default settings. This would ensure that any new fields or tables added to the system are automatically.

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

Users can define custom DataObjFormatters table formats and table aggregations for new tables manually, but they can't use our defaults.

Benefits:

• Enhanced User Experience: Users will benefit from seamless access to new tables in queries, QCBXs, and on the forms 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 DataObjFormatters 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 preview capabilities and functionalities.

[grantfitzsimmons]

Personally, I think this is something we should consider high priority in the same vein as #6233

@CarolineDenis Since we are testing the changes for that PR, could we fold this in at the same time?