Lodging "Continue" button still broken in v0.12.1

[valterschutz]

Bug Description

The lodging "Continue" button does not advance the form to the Media step in v0.12.1. This was previously reported in #984 and partially addressed by #1007 (which added res.ok checks and error toasts), but the root cause was not fixed and the bug persists.

Disclosure: This investigation was performed by an AI assistant (Claude Sonnet 4.6) by inspecting the compiled frontend JS from a running v0.12.1 container. The findings have not been verified by manually stepping through the source code.

Steps to Reproduce

1. Open the New Lodging dialog.
2. Fill in the Name field and select a Type.
3. Click Continue.

A "lodging save error" toast appears and the form stays on step 0. If the Type dropdown is left at its default empty placeholder, the button does nothing at all — no toast, no error, no feedback.

Expected Behavior

The form saves the lodging and advances to the Media step.

Screenshots / Logs

No response

Platform

Docker

Install Method

Docker Compose

AdventureLog Version

v0.12.1

Reverse Proxy

Nginx

Docker Compose / Relevant Variables (Optional)

Additional Context

Root Cause Analysis

There are two separate bugs.

Bug 1 — Silent no-op when Type is not selected

The Lodging object is initialised in the frontend with type: "" (empty string). The save handler has an early-return guard:

if (!o.name || !o.type || k || ...) return;

If the user hasn't selected a type, !o.type is true and the function returns with no feedback whatsoever.

Bug 2 — Missing trailing slash causes a silent 301 redirect

When a type is selected, the save handler POSTs to the wrong URL:

fetch("/api/lodging", { method: "POST", ... })
//          ^^^^^^^^ missing trailing slash

Django's APPEND_SLASH returns 301 Moved Permanently → /api/lodging/. Browsers follow 301 redirects from POST requests by downgrading to GET. The resulting GET /api/lodging/ returns 200 OK with the list of lodgings, not the newly-created object. Because the status is 200, the res.ok check introduced in #1007 does not catch this.

The code then processes the list response as if it were the created lodging — finds no .id — shows the lodging_save_error toast and reverts to step 0. This also explains the duplicate entries reported in #984: the GET that silently followed the redirect created nothing, so retrying creates a new lodging each time.

The same missing-slash issue exists in the PATCH call:

fetch(`/api/lodging/${ae.id}`, { method: "PATCH", ... })
// should be `/api/lodging/${ae.id}/`

Proposed fix:

1. Initialise type to "other" instead of "", or show a validation error on empty type.
2. Add trailing slashes to both fetch URLs:

   fetch("/api/lodging/", { method: "POST", ... })
   fetch(`/api/lodging/${ae.id}/`, { method: "PATCH", ... })

Confirmation

• I searched existing issues and confirmed this is not a duplicate.