Files
Forge-Engine/screens/widgets/data_definition_options.py
T
william aa3be503ce Expose relation fields in the champ pickers and fix their column resolution
data_definition_options() used to exclude relation-type fields from its field list entirely, so a filter/binding could never reference "the linked object" of a row — and even when a relation field's clean name was typed manually (as the earlier "level.parcour" example needed), it silently matched nothing: every column lookup for a filter/repeater field used the field's own name, but a relation is actually stored in a "<field>_id" column (see create_definition.py), so the lookup always missed.

Relation fields now appear in the champ dropdowns (Répéteur's filtre_champ/filtre2_champ, Donnée liée's data_filtre_champ/data_filtre2_champ) labeled with the object they point to (e.g. "parcour (→ parcours)"), and a new _field_column() helper in filter_repeater_rows.py resolves the right "<field>_id" column whenever the field turns out to be a relation — used consistently by the filter comparison itself, the "{{Objet.champ}}" dynamic-value resolver, the repeater's row content ({{champ}}), and the Donnée liée row context. Jauge's own champ/champ_nom pickers (which need an actual displayable value, not an id) still exclude relations, both server- and client-side.

Verified end to end: the dropdown shows the relation field with its target-object label, and filtering "level" rows by the clean relation field name "parcour" (not "parcour_id") against a dynamic {{game.current_parcours}} reference now actually matches, alongside the existing "number" filter. Full suite green (89).
2026-08-25 06:48:04 +02:00

41 lines
2.2 KiB
Python

import db
def data_definition_options(slug, definition_id):
"""Lignes et champs d'un objet de données, prêts à peupler un menu
déroulant — utilisé à la fois pour DEFINITIONS_DATA (tous les objets du
jeu, consommé côté client par les formulaires de la Logique de la
scène) et pour pré-remplir côté serveur les réglages qui dépendent d'un
objet déjà choisi sur un élément (ex: la Jauge — voir
controls_with_values.py). Chaque ligne est étiquetée avec la valeur de
son PREMIER champ (convention "premier champ = nom lisible", comme pour
un Répéteur), pour distinguer "Confiance" de "Trésorerie" plutôt que de
n'avoir que des numéros de ligne."""
if not definition_id or not slug:
return {"rows": [], "fields": []}
full = db.get_definition(slug, int(definition_id))
if not full:
return {"rows": [], "fields": []}
rows = db.list_rows(slug, full)
display_field = full["fields"][0]["name"] if full["fields"] else None
display_col = db.slugify(display_field).replace("-", "_") if display_field else None
row_options = [
{"id": r["id"], "label": f"{r.get(display_col)} (#{r['id']})" if display_col else f"Ligne #{r['id']}"}
for r in rows
]
# Les champs "relation" sont INCLUS (contrairement à avant) : un filtre
# de Répéteur/Donnée liée doit pouvoir comparer, par exemple, "le
# parcours lié" d'un niveau — ils restent identifiables via leur "type"
# pour les endroits qui n'en veulent pas (ex: le champ numérique suivi
# par une Jauge, voir controls_with_values.py). relation_definition_name
# (le nom de l'objet visé) sert uniquement à afficher un libellé clair
# dans la liste déroulante, ex. "parcour (→ parcours)".
definitions_by_id = {d["id"]: d["name"] for d in db.list_definitions(slug)}
field_options = []
for f in full["fields"]:
entry = {"name": f["name"], "type": f["type"]}
if f["type"] == "relation":
entry["relation_definition_name"] = definitions_by_id.get(f.get("relation_definition_id"))
field_options.append(entry)
return {"rows": row_options, "fields": field_options}