Editing and saving

One rule

Nothing on an edit page is saved until you press Save. Uploading a file saves immediately. Deleting a record asks first.

That covers everything, and it is worth stating plainly because the alternative - some fields saving as you type and others waiting - gives you no rule to learn. Adding a credit, adding an ISRC, reordering a track list, renaming a title: all of it is staged until you commit.

Where editing happens

Opening a record from a list puts it in a near-fullscreen dialog over the list you came from. The list stays where it was behind the dialog, and closing returns you to it with your scroll position and search intact.

The dialog shrinks to fit its content, capped at 95% of the window - a label with one field gets a small dialog, a release gets a large one. Once the content is taller than that, the title bar stays pinned while the body scrolls underneath.

Opening the same URL directly - a reload, or a link someone sent you - renders the identical content as a full page instead. Nothing is lost either way; the surface just differs.

The toolbar

The record's name sits at the top left, the actions at the top right.

On a full page the two commit actions collapse into a single Save, and there is no Cancel: leaving the page is the discard.

The commit actions are hidden rather than greyed out when there is nothing to save, because a permanently disabled button reads as broken. After a successful save, Saved. appears next to them.

Discarding

Cancel discards without asking - it is a deliberate press. Esc and a click on the backdrop still confirm first, because those are the ones you hit by accident. Navigating away from a full page with unsaved changes warns you as well.

Actions that need a save first

Two things read stored state rather than what is on screen, so they are disabled while there are unsaved changes, with a line explaining why:

• New recording on a release - it creates a recording and navigates to it, and leaving would discard the release edits.
• Validate and Download XML in DDEX ERN validation - they build the message from the saved release, so they would otherwise report on stale data.

If a save fails

A save runs several steps in order - the record itself, then the credits, the identifiers, the track list - and stops at the first one that fails, naming it. It is not a single transaction, so some steps may already have gone through.

That is safe to retry: pressing Save again finishes the job rather than duplicating it. Each step compares what is on screen against what is in the database and only writes the difference, and parties invented in the editor are matched by name, so a retry finds the one already created instead of making a second.

Deleting

Delete lives in the … menu and always confirms. Before it offers to delete anything, it checks what still points at the record:

When something is in the way, the dialog names it - "2 recordings and 1 release" - and links to each record so you can clear the assignments. The check runs once more at the moment you confirm, so a record that was assigned to something in the meantime is not deleted behind your back.