COG Inheritance: Allow COG siblings to inherit primary CO's catalog number

[grantfitzsimmons]

In light of recent feedback from the Swiss GeoSpecify Steering Committee team, it has become evident that the current implementation of Collection Object (CO) and Collection Object Group (COG) management in Specify 7 could be enhanced to better support their workflows.

For their collections, there is a concern regarding the uniqueness of catalogNumbers, as multiple COGs and COs can currently share the same names and numbers, leading to confusion and potential data integrity issues. In some cases, there is a desire for a more robust system where each geological object must maintain a single, unique catalog number, meaning all COG siblings must share that number while it remains unique within the collection.

These siblings must appear in queries when the number is searched. The catalog number should be shared among all siblings, regardless of the format defined for the type. It must also be possible to add siblings with a manually assigned catalog number when necessary.

Requirements

Note

These requirements are broken down more in-depth in the sub-issues associated with this. Please read those in-depth as well and review all associated documents during implementation.

This issue provides an overview of the goal, context, and big-picture requirements, and the sub-issues should be referenced as requirements for specific components of this effort.

1. Catalog Number Definition:

   • In most cases, a catalogNumber will be defined for the primary CO (Collection Object).
   • A catalogNumber is not required to be defined for the primary CO, and if none is defined, all described logic in this issue will be unused.

2. Inheritance of Catalog Numbers:

   • From a user's perspective, if a catalogNumber is defined for the primary CO, any COG siblings that do not have a catalogNumber will inherit the primary CO's catalogNumber.
   • The inherited catalogNumber for these siblings should be displayed as grayed out in the COG form where the catalogNumber would usually be shown.

3. Manual Assignment of Catalog Numbers:

   • Users should have the ability to manually assign a catalogNumber to any COG sibling, regardless of whether the sibling is inheriting a catalogNumber from the primary CO.
   • Manual assignments should take precedence over inherited values.

4. Scope of Behavior:

   • This inheritance and display behavior only applies to COGs with a super type of consolidated.
   • For COGs with a super type of discrete or drill core, this behavior will not be implemented.

5. Business Logic for Queries/Exports/Form Views:

   • When performing queries, exports, or displaying form views, the system should utilize business logic to fill sibling catalogNumbers with the value of the primary CO’s catalogNumber when applicable, but only if the sibling's catalogNumber is empty, using only a placeholder.
   • This should not be copied, but rather inherited, and any empty catalogNumber fields are to remain empty unless assigned a value manually by the user.
   • This logic should ensure that manually assigned catalogNumbers are not overwritten by the primary catalogNumber.

Additional Considerations:

• Ensure that the user interface clearly indicates when a catalogNumber is inherited versus manually assigned, particularly for consolidated COGs (e.g., the value is grayed out (placeholder), but the field is not disabled, and a new value can be added).
• Write user documentation on this logic.