#539. Ross: "After looking at options in a position your full back/centre back who you marked as a centre back is actually better at full back so you move them to that position instead." The depth board is where the app produces the evidence that a filing is wrong, so it is where the correction belongs. The menu below is the whole of the interaction.
Everything here is live — hover Filed under, click a position, watch the dot move. The green dot is
the same marker the player card uses for the filed position (PlayerCardView.xaml:809), so
the two screens say the same thing the same way.
Today — three items
Proposed — a fourth, with his own positions under it
His own positions, not all ten. #495 stores every position FM lists for him as a row and settles one of them; this picks a different row. Offering the full ten would let you file a centre back as a striker, which is not a correction — it is a new mistake. Amad reaches four groups, which is why he is the example: he is also the man the old bucketing filed under Defenders.
Groups, not places. The list names groups rather than sided positions, because that is what is
being answered — a man who plays left and right full back has two Full Back rows and one answer.
Names come from PositionNaming.Name, so the menu reads the way the rest of the app does.
Settled — somebody answered at a capture
The dot is the answer. Clicking another moves it — one click, no dialog, no save button.
Unsettled — nobody has said yet
Nothing is filed, so nothing carries a dot. The app still has to put him somewhere and falls back to the first of his positions in the running order (#494) — so that one is marked assumed rather than chosen. Seventy of ninety-six players in the real save are in this state, so it is the common one, not the edge.
One position only — nothing to decide
A flat D (C) has one candidate, so the submenu is a read-out rather than a choice — shown,
not hidden, because seeing where he is filed is worth the row even when you cannot change it.
Twenty-nine of ninety-six are like this. Illustrative player.
Recommended
Right-click, hover, click. The current answer is visible in the same gesture that changes it, and
the menu already knows which player you hit — SetContextMenuPlayer runs on
ContextMenuOpening, before the items render.
Rejected
EditLoanClubDialog is the precedent #495 reached for, and it earns its modal: a club is
one of hundreds and needs a search. This is a choice between two and four items you can already see.
A modal for that is three extra clicks and a thing to dismiss.
Rejected
File under Wing Back, File under Wide Midfielder… The menu then changes height per player, from four items to seven, and the three commands that have nothing to do with filing get pushed around by a player's position list.
| Question | Options | Recommendation |
|---|---|---|
| Slot rows too, or only the pool? | The pool is where the comparison happens, but a man in a slot is also on this screen, and his menu already runs the same handshake. | Both. Same command, same list. A menu that appears on one row and not the one beside it is harder to explain than an extra item. |
Is it gated by IsPlanEditable? |
An old season's board is read-only, and every other write on this screen respects that. | No — and the store already settled the trap.
PlayerStore.SettlePositionsAsync writes the open spell only: "a closed one is
history, and where a man used to be filed is not a thing anybody is editing." So refiling from a
past season's board changes where he is filed now, not what he was then — which is what the
gesture means anyway. It also refuses a group that is not among his own rows, so the menu and the
store agree without either trusting the other. |
| A "Not filed" option to clear it? | Null is a real state — it means nobody has said, and the app falls back to the running order. | No, in v1. Once you have looked at a man you cannot honestly go back to
not knowing, and SquadSpellRules already clears the answer by itself when his positions
change so far it becomes impossible. |
| Does the board rebuild under you? | Refiling changes which shelf he is on, so with a filter active he can vanish from the list you just right-clicked. | Let him go. That is the filter doing its job, and it is the visible proof the change landed — but the issue should say so rather than leave it as a surprise. |
Not covered here: a history of where he has played. That was considered and rejected as a use for this
field — SettledGroup records how he is filed, and it moves both when he genuinely changes
position and when you simply correct a mis-click, which is not a distinction it can make. The spell already
splits on FM's own position string, which is the real retraining event.