Explicit folder membership should beat a Docker label claim (both client and server)

[chodeus]

Problem

A container can be explicitly assigned to one folder and label-claimed by another at the same time. Which folder wins is decided by iteration order, in both the client and the server, so the outcome is arbitrary rather than intentional.

Raised by review on #54 and deliberately deferred there: #54 exists to remove divergence between the client and server membership calculations, and making only the PHP deterministic would have introduced a new one.

It is reachable through normal use

scripts/folder.js:271-276 partitions the editor's container list:

selectedRegex = choose.filter(el => el.Label === fldName);   // labelled for THIS folder
choose        = choose.filter(el => el.Label !== fldName);   // everything else

Containers labelled for the folder being edited become checked disabled and are excluded from the save (:checked:not(:disabled), folder.js:480) — the label owns them and the editor will not let you override it.

A container labelled for a different folder stays in choose and renders as a plain, enabled, unticked checkbox with no indication it is already claimed. So: label a compose service folder.view3: Media, later open the Downloads folder editor, tick it, save. Two clicks, no warning.

Why the outcome is arbitrary

Client — scripts/docker.js:305 adds label matches with only !combinedContainers.includes(el); there is no explicit-membership check. Each container row is physically moved into the first folder that claims it, so whichever folder renders first wins.

Server — server/lib.php (syncContainerOrder) filters members against $assignedContainers, so the first folder in iteration order wins.

The two also iterate differently: PHP walks $folders in docker.json key order, the client renders in Unraid display order. For a contested container they can therefore disagree with each other as well as being individually arbitrary.

Proposed fix

Make explicit membership beat a label claim, in both places in one change, since explicit assignment is a deliberate user action and a label is a standing default:

• docker.js — exclude containers explicitly listed in any folder's containers[] from label matching
• lib.php — track explicit members separately from label claims, and skip label assignment for names already in the explicit set (the shape review proposed on fix: match autostart membership to what the UI renders #54)

Worth considering alongside: surface the claim in the editor, so a container labelled for another folder is visibly marked rather than appearing as a free checkbox.

Acceptance

• A container explicitly in folder A and labelled for folder B renders in A, regardless of folder order
• The autostart file agrees with that placement
• A container labelled for B with no explicit assignment anywhere still lands in B