Problem ------- Given (see example structure in attachment): * a field `Field 1` * with `a` as (default) value * only submitable, no update permissions * a field `Field 2` * with `d, e` as values * submitable & updatable * a field `Field 3` * with `g, h` as values * submitable & updatable * the following field dependencies matrix: * `Field 1(a)` ➡️ `Field 2(d, e)` * `Field 2(d)` ➡️ `Field 3(g)` * `Field 2(e)` ➡️ `Field 3(h)` When users try to submit an artifact, then field dependencies are not propagated: choosing `Field 2(d)` or `Field 2(e)` does not change anything for `Field 3`. ☹️ Note: everything is fine at the update of the artifact though. Analysis -------- * Everything works pretty fine if ListPicker is disabled. * In artifact edition, only field dependencies are initialised at page load. ListPicker is initialised only when the fields enters in edition. * If we defer the initialisation of field dependencies so that they initially run after the initialisation of ListPicker, then all is back to normal. * Event soup: both ListPicker and field dependencies listen to `change` event and manipulate the native `<select>` element. Conclusion: I don't know exactly where, but it appears that at some point there is a race condition between ListPicker and field dependencies initialisations. Solution -------- The field dependencies initialisation is now run **after** the load of ListPicker. This is done everywhere field dependencies are applied: * submit, * edit, * copy, * masschange, * artifact modal v1 (in artifact link -> create artifact) --- Closes request #23051: Field dependencies issue at artifact creation Change-Id: If0f6a910e52069bd30a1df25892e557a3aa32748

+87 −14

Author

Nicolas Terray (nterray) 2021-09-21 14:15

Committer

Nicolas Terray (nterray) 2021-09-21 14:51

Hash 083c417a22d9449dcf1401fdf5c8db8fd6e48303

Parent 777cb12a1363109216205328739648d9d29900f1

Reference git #tuleap/stable/083c417a22d9449dcf1401fdf5c8db8fd6e48303