fix(marketplace): track adoptions through a course roll-forward - #8547
Merged
adi-herwana-nus merged 1 commit intoAug 13, 2026
Merged
Conversation
Adoption rows were keyed off the SOURCE's own marketplace listing, so they only ever fired for copies of the authoring assessment. A copy of an adopted copy -- next semester's course, rolled forward -- carries no listing of its own, so it dropped out of the listing's reach silently: no adoption row, no "a newer version is available" reminder ever again, and the count missed a course genuinely using the content. Key the row off the source's own adoption row instead. The chain now propagates through every generation, and each copy inherits the vintage its source holds rather than what the listing currently serves, so a rolled-forward copy is still told when it falls behind. Copies of the assessment that AUTHORS a listing stop being recorded. Those are the publisher's own -- their course rolled forward, or the assessment handed to a colleague directly -- made without anyone choosing the listing, and recording them let a listing with no adopters at all show an adoption count that climbed every semester its author re-ran the course.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes marketplace adoption tracking so that adoption records and version-reminder reach propagate through “roll-forward” generations (copy of an adopted copy), while excluding duplicates of the publisher’s own authoring assessment that did not come through a marketplace adoption.
Changes:
- Update
Course::Assessment#record_marketplace_adoptionto key propagation off the source assessment’s existing adoption row (preserving the adopted vintage), rather than the source’s marketplace listing. - Add model-level specs covering: no-op for listing authoring copies, propagation from adopted copies, vintage inheritance, unlisted listings, and preview container exclusion.
- Update duplication job specs to reflect the new distinction between duplicating the listing’s authoring assessment vs duplicating an adopted copy (roll-forward propagation).
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| spec/models/course/assessment_spec.rb | Adds focused coverage for adoption propagation semantics and edge cases. |
| spec/jobs/course/assessment/marketplace/duplication_job_spec.rb | Adjusts expectations for manual duplication to distinguish authoring copies vs adopted-copy roll-forward. |
| app/services/course/duplication/base_service.rb | Updates inline documentation to reflect adoption propagation intent for duplication paths outside the marketplace job. |
| app/models/course/assessment.rb | Implements propagation via the source adoption row and preserves the source’s adopted vintage timestamp. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
adi-herwana-nus
deleted the
lws49/fix-marketplace-adoption-roll-forward-rebased
branch
August 13, 2026 17:22
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adoption rows were keyed off the SOURCE's own marketplace listing, so they only ever fired for copies of the authoring assessment. A copy of an adopted copy -- next semester's course, rolled forward -- carries no listing of its own, so it dropped out of the listing's reach silently: no adoption row, no "a newer version is available" reminder ever again, and the count missed a course genuinely using the content.
Key the row off the source's own adoption row instead. The chain now propagates through every generation, and each copy inherits the vintage its source holds rather than what the listing currently serves, so a rolled-forward copy is still told when it falls behind.
Copies of the assessment that AUTHORS a listing stop being recorded. Those are the publisher's own -- their course rolled forward, or the assessment handed to a colleague directly -- made without anyone choosing the listing, and recording them let a listing with no adopters at all show an adoption count that climbed every semester its author re-ran the course.