From 1b1c178c092e85594c9075c135efe00223626ce1 Mon Sep 17 00:00:00 2001 From: funman300 Date: Tue, 4 Aug 2026 21:20:06 -0700 Subject: [PATCH] fifa17-recon: /club honours ?type= -- the STAFF tab was showing footballers Observed live: the staff tab issues GET /club?year=2017&type=manager&count=200. club_route ignored the parameter entirely and answered every type with the full player list, so FUT displayed players as coaching staff. The filter is deliberately narrow. 'player' and 'manager' are the only values the client has ever been seen to send; 'custom' (the by-league and by-team drill-downs) and a missing type keep exactly the behaviour that is already proven on screen, because those drill-down counts were only just fixed and must not be disturbed. An unrecognised type is filtered rather than answered with everything, since answering an unknown question with the whole player list is the bug being fixed. We own no staff cards, so type=manager is [] today -- an empty item list, the same shape the itemData parser already accepts everywhere else. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW --- fifa17-recon/tools/utas_server.py | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/fifa17-recon/tools/utas_server.py b/fifa17-recon/tools/utas_server.py index 33c97b2..ce400d5 100755 --- a/fifa17-recon/tools/utas_server.py +++ b/fifa17-recon/tools/utas_server.py @@ -1409,7 +1409,30 @@ def club_route(h): if sweep_window(): return 200, {"itemData": sweep_items()} items = STORE.items() - if CLUB_PAGE: + + # HONOUR ?type=. This route ignored it, so the STAFF tab -- which asks for + # type=manager, observed live 2026-08-04 -- was answered with the player list + # and displayed footballers as coaching staff. + # + # Filtering is deliberately NARROW. `player` and `manager` are the two values + # actually observed; `custom` (the by-league and by-team drill-downs) and a + # missing type keep exactly the behaviour that is already live-proven on + # screen, because the drill-down counts were only just fixed and this must not + # disturb them. An unrecognised type is treated like manager -- filtered, not + # unfiltered -- since answering an unknown question with the whole player list + # is what produced this bug in the first place. + kind = "" + if "?" in h.path: + for part in h.path.split("?", 1)[1].split("&"): + if part.startswith("type="): + kind = part[5:] + if kind and kind not in ("player", "custom"): + # cardsubtypeid 0..3 is a player (FUN_1800d8330); everything else is + # staff or a manager. We own no staff cards yet, so this is [] today -- + # an empty item list, which is the same shape the parser already accepts. + items = [i for i in items if i.get("cardsubtypeid", 0) not in (0, 1, 2, 3)] + log(" CLUB: type=%s -> %d item(s) (players filtered out)" % (kind, len(items))) + elif CLUB_PAGE: log(" CLUB: returning %d item(s) [FUT_CLUB_PAGE experiment -- compare this " "number against the MY CLUB counter on screen]" % len(items)) return 200, {"itemData": items}