Transfer a paper's project to a different venue

[epignatelli]

Goal

Let a paper be moved from one venue's board to a different venue's board — e.g. it's rejected from ICLR and the lab decides to resubmit it to NeurIPS instead, without re-registering it from scratch and losing its history/discussion/checklist state.

Who can do it

Only the paper's owner (card.submittedBy.email) or a PI — deliberately not admins. This is a different permission set from everything else in the app, which mostly uses hasFullWrite() (PI or admin) for cross-card actions — see firestore.rules' existing boards/{boardId} rules and docs/FIREBASE.md's Security Rules section for the established pattern. Worth confirming with Eduardo before building, since it's the first place in the app admins are deliberately excluded from something PIs can do.

Why this isn't a simple field update

A card lives at boards/{boardId}/cards/{cardId} — moving venues means moving across Firestore subcollections, not editing a field in place. That's a create-in-the-new-parent + delete-from-the-old-parent, not a single-document write, and needs to either be atomic (a transaction/batch) or built so a partial failure (created in the new venue but not yet removed from the old one, or vice versa) is safely recoverable rather than silently duplicating or losing the paper. deleteBoardData()/saveBoard()'s existing batch patterns are a reasonable starting point to build from.

Open questions to resolve before building

• Confirm the owner-or-PI-only (no admin) permission with Eduardo — is that intentional, or should admins have it too for cases where the owner/PI can't act?
• Does the card's status reset on transfer (e.g. back to register), or carry over as-is? Different venues can have very different schedules/requirements.
• Does checklist/reviewers/jrReviewState/srReviewState reset (new venue likely means a fresh internal review pass), or carry over?
• Keep discussion/history — almost certainly yes, that's the whole point of not re-registering from scratch. Add a history entry for the transfer itself ({timestamp, actor, action: 'transferred', note}, same shape already used for registered).
• Does the old venue's .ics feed need updating (a card being removed doesn't currently change a venue-level .ics, since that's built from venue dates, not cards — probably no-op, but worth double-checking syncVenueIcs's scope).

Not blocking anything else

Independent of what's shipped or in progress — venue proposals, the review-approval flow, etc. Purely additive.