[Feature request] transfer trip ownership

[kjake]

Use case

Trips are often planned by one family/group member but logged by another, and over time the "owner of record" should be able to change without losing data. A few concrete scenarios:

• Family trips planned by parent on behalf of a child. A parent creates trips for school field trips, sports/band travel, or college visits while the child is too young or doesn't yet have an account. Once the child gets their own Trek account, they should become the owner of those past trips so they show up in their own history (and atlas).
• Two-account households. When a couple shares trip-planning duties, sometimes the wrong account ends up creating a trip. Today the only way to "fix" it is to delete and recreate from scratch — losing all reservation, accommodation, place, and budget detail.
• Account migration. If a user retires an account (e.g. switches from a personal email to a self-host SSO setup), they currently have no way to bring their existing trip history with them.

Current behavior

Looking at services/tripService.ts and routes/trips.ts:

• trips.user_id is the owner column. It's set at trip creation (createTrip) and never updated by any API endpoint — there's no "transfer" or "set owner" route.
• DELETE /api/trips/:id/members/:userId (the "Leave trip" UI) only operates on the trip_members table. The owner isn't represented there, so an owner cannot leave their own trip — and even if they could, ownership wouldn't pass to anyone else.
• users.id is referenced by trips.user_id with ON DELETE CASCADE, so deleting an account also deletes every trip that user owned, regardless of how many other members were on those trips.

The combination means there is no path — UI, API, or otherwise — to keep trip data alive while changing who owns it.

Proposed behavior

Add a POST /api/trips/:id/transfer endpoint that lets the current owner transfer ownership to any existing trip member. Roughly:

router.post('/:id/transfer', authenticate, (req, res) => {
  const { newOwnerId } = req.body;
  const access = canAccessTrip(req.params.id, authReq.user.id);
  if (!access || access.user_id !== authReq.user.id)
    return res.status(403).json({ error: 'Only the current owner can transfer this trip' });

  // newOwnerId must be an existing member
  const isMember = db.prepare(
    'SELECT 1 FROM trip_members WHERE trip_id = ? AND user_id = ?'
  ).get(req.params.id, newOwnerId);
  if (!isMember) return res.status(400).json({ error: 'New owner must be a current trip member' });

  // Transfer in a transaction:
  //   1. UPDATE trips SET user_id = ? WHERE id = ?
  //   2. DELETE the new-owner row from trip_members (since owner isn't in that table)
  //   3. INSERT the previous owner into trip_members (so they stay on the trip as a member)
  // ...
});

Companion UI surface: an extra option in the trip's settings/members panel, visible only to the current owner — "Transfer ownership to ___ (member)".

Considerations

• Audit logging. writeAudit should record the transfer with both the previous and new owner email — important for shared-instance trust.
• Permissions on member-set actions. Existing permission checks key off trip.user_id; the transition should be atomic so no request is in-flight against the old owner mid-transfer.
• Auto-join the previous owner as member. Otherwise the previous owner would lose access entirely after the transfer, which is rarely the intent.
• Refuse if the new owner isn't already a member. Forces an explicit invite + accept flow before the transfer (existing path) and avoids surprise account links.
• Atlas / stats. Atlas country/region counts are computed per-user from the trips they own, plus their manually-marked entries. Ownership transfer should re-attribute the trip's places to the new owner's atlas. (Verifying this is just a re-query — Atlas isn't denormalized.)

Optional follow-up: graceful account deletion

The cascade-delete behavior of users.id makes account deletion irreversible for any shared trip. Pairing the transfer feature with a "before deleting your account, transfer or delete your owned trips" flow would close the data-loss footgun.

[mauriceboe]

You can now transfer a trip to another member from the share dialog — the new owner takes over and you stay on as a member. Shipping in 3.2.0. Thanks for the request!