Repository navigation
Provide a way to list Sources that are collected by a particular Source #214
Description
Context
Currently at the Source level there is no filtering on the collected_by field.
When vendors are building systems which list content stored in TAMS then they are only looking for the Sources at the top of the content tree.
In many cases this is the multi-Source, however due to single essence (eg audio only) workflows then this is not a reliable method of finding the top level content.
To achieve this they must go through every result and look to see if the collected_by field is missing as this then indicates that it is the top of a Source collection.
This process can also throw any form of sensible pagination in a client application as when requesting content from the TAMS API it is not known how many results will be retained or discarded.
Actions
Decide how filtering by collected_by should work, and write an ADR and associated spec change
Plan to make the matching change to Flows for consistency and covienience
Outcome
- ADR
- New query string parameter
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
samdbmg commentedon Jun 26, 2026
TSC 2026-06-26
Thanks to @danjhd for supplying a bunch of thinking on this and doing the OpenAPI work on this.
Implementation complete, ready for review.
samdbmg commentedon Jul 24, 2026
TSC 2026-07-24
JS: Discussion on whether to add
collects_idsalong withcollected_by_idsto be able to explore the hierarchy in both directionsGSP: Fewer queries is quite valuable, and being able to find the info you need in a single request
JB: Is the other direction useful though. Can already find the top of the tree
GSP: No clear use case right now, but the flexibility is valuable
JB: Will have another look
GSP: Will offer some thoughts
samdbmg commentedon Aug 7, 2026
TSC 2026-08-07
JB: Were we going to add the reverse?
JS: Were unsure if the complexity was due
JB: I've drafted the spec updates
JS: Does that mean we should add it?
GSP: Haven't been able to find any use cases yet, but primarily because I was on holiday
JB: Aware we're running out of time to land this for IBC
JS: If we're comfortable we should merge it. If not let's merge what we have and then extend in future if we need it
JB So we merge what we have. If someone comes along for the other direction, we can do it.
JB: Leaves the non-linear history problem to resolve
SMG: Will fix on Monday.