rbrooks/Quest-Board

Watch

Fork 0

An imported campaign's rule cards do not re-link to the rules pack they came from #1070

New issue

Closed

opened 2026-10-04 03:51:59 +00:00 by claude-bot · 2 comments

claude-bot commented

2026-10-04 03:51:59 +00:00

Collaborator

Split out of #991, which now covers only files (handout files and map originals).

What

A rule card made from a rules pack keeps a link to that pack's entry. A campaign export does not carry that link in a form an import can restore, so after an import the cards are there but stand alone: they no longer point back to the pack.

Why this is its own issue

It involves no files. It needs pack matching on import, the same problem #1053 solved for character sheet definitions: the importing install may have the same pack, a different version of it, or not have it at all.

Intended approach

Follow the sheet-definition pattern from #1053:

Export: each card carries a stable reference to its pack and entry (pack identity and version, entry key), not a database id.
Import:
- the same pack and version is present: re-link;
- the pack is present at a different version: re-link only if the entry key still exists, otherwise leave the card standing alone;
- the pack is absent: leave the card standing alone. It must still import and read correctly.
Report: the import's summary says how many cards were re-linked and how many were not.
A new export schema version; an older file imports as it does today.
Round-trip tests for each of the three import cases.

Not planned for 4.5.0.

Split out of #991, which now covers only files (handout files and map originals). ## What A rule card made from a rules pack keeps a link to that pack's entry. A campaign export does not carry that link in a form an import can restore, so after an import the cards are there but stand alone: they no longer point back to the pack. ## Why this is its own issue It involves no files. It needs pack matching on import, the same problem #1053 solved for character sheet definitions: the importing install may have the same pack, a different version of it, or not have it at all. ## Intended approach Follow the sheet-definition pattern from #1053: - **Export:** each card carries a stable reference to its pack and entry (pack identity and version, entry key), not a database id. - **Import:** - the same pack and version is present: re-link; - the pack is present at a different version: re-link only if the entry key still exists, otherwise leave the card standing alone; - the pack is absent: leave the card standing alone. It must still import and read correctly. - **Report:** the import's summary says how many cards were re-linked and how many were not. - A new export schema version; an older file imports as it does today. - Round-trip tests for each of the three import cases. Not planned for 4.5.0.

claude-bot referenced this issue

2026-10-04 06:56:54 +00:00

Campaign export leaves out quest details, character sheets, maps and handout files #991

claude-bot referenced this issue

2026-10-04 10:33:01 +00:00

Campaign export leaves out quest details, character sheets, maps and handout files #991

claude-bot commented

2026-10-05 03:19:58 +00:00

Author

Collaborator

Picking this up, on feat/1070-rule-cards-relink.

First, the facts. This issue was written from a summary, not from the code. Before anything is built, the delegate establishes:

which campaign rows point at a pack or a pack entry;
what the export writes for each today;
how a pack and an entry can be identified on another server.

If the premise is wrong, nothing is built and I report what is actually the case.

If it holds: the approach in the issue, as export schema 19. One addition: a card is never re-linked to a pack that is disabled or under a rightsholder notice.

A decision this may need: if packs and entries have no identity that is stable across servers, providing one is a design choice, and I will ask on the Questions page before building it.

**Picking this up**, on `feat/1070-rule-cards-relink`. **First, the facts.** This issue was written from a summary, not from the code. Before anything is built, the delegate establishes: - which campaign rows point at a pack or a pack entry; - what the export writes for each today; - how a pack and an entry can be identified on another server. If the premise is wrong, nothing is built and I report what is actually the case. **If it holds:** the approach in the issue, as export schema 19. One addition: a card is never re-linked to a pack that is disabled or under a rightsholder notice. **A decision this may need:** if packs and entries have no identity that is stable across servers, providing one is a design choice, and I will ask on the Questions page before building it.

rbrooks referenced this issue from a commit

2026-10-05 04:04:34 +00:00

feat(webapp): an imported campaign's rules find their content pack again (#1070)

claude-bot referenced this issue from a pull request that will close it,

2026-10-05 04:51:43 +00:00

An imported campaign's rules link back to their content pack (export schema 19) (#1070) #1094

claude-bot referenced this issue

2026-10-05 04:51:50 +00:00

An imported character sheet keeps the old server's pack and record ids in its content rows #1095

claude-bot referenced this issue

2026-10-05 04:52:16 +00:00

An imported character sheet keeps the old server's pack and record ids in its content rows #1095

claude-bot closed this issue

2026-10-05 05:26:32 +00:00

claude-bot referenced this issue from a commit

2026-10-05 05:26:33 +00:00

Merge PR #1094: an imported campaign's rules link back to their content pack (export schema 19) (#1070)

claude-bot commented

2026-10-05 05:26:38 +00:00

Author

Collaborator

Done: PR #1094, merged to main (export schema 19). CI was green on the PR's head.

The premise held: shelf cards, pinned rules, prep items and "Based on" wiki pages all lost their link in an import.
Now: each is named in the file by its pack's key and the record's kind and slug, never by an id. An import links it to this server's record when the pack is there, and leaves it standing alone when it is not.
Never linked: a pack that is disabled, of another game system, under an undecided notice, or a campaign's own.
Reported on the import's result screen: how many linked, and how many did not and why.
No migration.

Limit: a pack whose key comes from its file name is not recognised under a different file name on another server.

Not done: an independent review; a look at the new banner in a browser.

Follow-up: #1095, character sheet rows keep the old server's ids. Checked: the existing guard stops that reaching another campaign's content, so it is a lost link only.

Reaches dev with the next prerelease.

**Done: PR #1094, merged to main (export schema 19). CI was green on the PR's head.** - **The premise held:** shelf cards, pinned rules, prep items and "Based on" wiki pages all lost their link in an import. - **Now:** each is named in the file by its pack's key and the record's kind and slug, never by an id. An import links it to this server's record when the pack is there, and leaves it standing alone when it is not. - **Never linked:** a pack that is disabled, of another game system, under an undecided notice, or a campaign's own. - **Reported** on the import's result screen: how many linked, and how many did not and why. - No migration. **Limit:** a pack whose key comes from its file name is not recognised under a different file name on another server. **Not done:** an independent review; a look at the new banner in a browser. **Follow-up:** #1095, character sheet rows keep the old server's ids. Checked: the existing guard stops that reaching another campaign's content, so it is a lost link only. Reaches dev with the next prerelease.

rbrooks referenced this issue from a commit

2026-10-05 05:54:41 +00:00

fix(webapp): an imported sheet's rows find their content pack again, and no id from a file is stored (#1095)