COG Inheritance: Query Behavior for Catalog Numbers

[grantfitzsimmons]

This focuses on expanding Query Builder (QB) functionality to improve the handling of catalog numbers for Collection Objects (COs) and Collection Object Groups (COGs).

1.A: Query Backend Logic

• Functionality:
• When a user enters a catalog number in the query field filter, the backend will:
  • Determine if the corresponding CO is part of a COG.
  • If the CO is part of a COG, execute additional logic to check for siblings with empty catalog numbers.
  • If the CO is not part of a COG, apply the standard query logic.

1.B: Return Sibling Catalog Numbers

• Functionality:
• If the CO belongs to a COG and siblings with empty catalog numbers are detected:
  • Return each sibling as a new entry in the query results (new lines).
  • Populate the catalog number column with the catalogNumber of the primary CO in the COG for siblings without an assigned catalog number.

Query Filters

• Query filters must be automatically applied to any new lines added to the query. This means that if a user adds a new condition, it should influence the results of all relevant entries in the query.

2. Hierarchy of COG and Children:

   • For example, let's say a COG has three children of different types:
     • Meteorite
     • Rock
     • Mineral
   • When any filters are applied to the query, it affects the visibility of its children based on the specified criteria. The additional rows added are filtered just as they would if they were returned in the original query.

3. Filter Logic:
   In this example:

   • If a user specifies a filter with Type = Meteorite:
     • Only Meteorite entries will be returned, and entries of the sibling type (Rock and Mineral) will be excluded.
   • If a user specifies a filter with Type = any:
     • All entries (Meteorite, Rock, and Mineral) will be returned.
   • If a user specifies a filter with Type = Rock:
     • Only Rock entries will be returned, even if that means excluding the primary COG and its sibling types (Meteorite and Mineral).

4. Applicability to All Query Fields:

   • The above logic applies to any type of field in the query filters. This means that similar rules should be followed for any other attribute added to the query, ensuring consistent behavior across different filter types.