Notes
https://docs.google.com/document/d/1m1IZuXu_aEv8K-Or8ubWnEgzm100dWpUjIf2tTBS4K8/edit?usp=sharing
When a user is listed as a coauthor on a deposit, and that user owns a collection, we’d like the dataset to be automatically added/linked to that collection—provided we can reasonably verify the coauthor’s identity.
This request comes up frequently in Support and is one of a broader set of improvements around collections and author linking.
Problem / Motivation
Currently, if a user is a coauthor on a deposit and they also have a collection, there is no automatic association between the new deposit and that collection. This leads to:
Extra manual work for authors to keep their collections in sync with their publications.
Inconsistent visibility of an author’s full body of work across the platform.
Repeated support tickets asking why co-authored datasets are not visible in the coauthor’s collection.
We’d like to reduce friction for users and support, and make collections better reflect an author’s complete set of contributions.
Proposed Behavior
When a new deposit is created or updated:
- For each coauthor on the deposit, check whether they have a collection.
- If yes, attempt to verify that the coauthor record matches a user account with a collection using one or more of the following metadata fields:
- ORCID
- ROR-affiliated institution and affiliation match
- Email (if applicable/available)
- Other existing unique identifiers
- If a sufficiently confident match is found, automatically:
- Link the dataset to that coauthor’s collection, or
- Prompt the user (e.g., the corresponding author or the coauthor) to confirm the link, depending on UX decisions.
- Ensure the linkage respects any existing permissions, privacy, or ownership rules for collections.
If identity cannot be reasonably verified, do not auto-link
Scope / Constraints
This feature can initially be limited to authors with strong, unique identifiers (e.g., ORCID) to avoid incorrect matches.
Behavior should be configurable or limited to specific collection types if needed.
Consider whether this applies only to newly created deposits, or should also be retroactively applied (e.g., via a one-time migration or background job).
Acceptance Criteria
- When a deposit is created with a coauthor whose identity can be verified (via ORCID or other agreed-upon metadata), and that coauthor has a collection, the dataset is automatically added/linked to that collection.
- When verification is ambiguous, the system does not auto-link and no incorrect associations are created.
- Support documentation (or release notes) describes the new behavior so Support can point frequent requesters to it.
- Logs or admin tooling exist to help debug or correct incorrect linkages if they occur.
Notes
https://docs.google.com/document/d/1m1IZuXu_aEv8K-Or8ubWnEgzm100dWpUjIf2tTBS4K8/edit?usp=sharing
When a user is listed as a coauthor on a deposit, and that user owns a collection, we’d like the dataset to be automatically added/linked to that collection—provided we can reasonably verify the coauthor’s identity.
This request comes up frequently in Support and is one of a broader set of improvements around collections and author linking.
Problem / Motivation
Currently, if a user is a coauthor on a deposit and they also have a collection, there is no automatic association between the new deposit and that collection. This leads to:
Extra manual work for authors to keep their collections in sync with their publications.
Inconsistent visibility of an author’s full body of work across the platform.
Repeated support tickets asking why co-authored datasets are not visible in the coauthor’s collection.
We’d like to reduce friction for users and support, and make collections better reflect an author’s complete set of contributions.
Proposed Behavior
When a new deposit is created or updated:
If identity cannot be reasonably verified, do not auto-link
Scope / Constraints
This feature can initially be limited to authors with strong, unique identifiers (e.g., ORCID) to avoid incorrect matches.
Behavior should be configurable or limited to specific collection types if needed.
Consider whether this applies only to newly created deposits, or should also be retroactively applied (e.g., via a one-time migration or background job).
Acceptance Criteria