Found while following the skill on a Jmix 2.8.2 project.
Problem: silent — the skill covers passing state into a detail view only through DialogWindows, and says nothing about the declarative handlers or the open mode they depend on.
Task
An Order list view is reused in three departments. A new Order created from a department must receive that department before the detail view builds its OrderType combo box, so the combo offers only the types allowed there.
Where
The "Create Child Entity From Selected Master" step passes state with DialogWindows.detail(...).withInitializer(...). The declarative equivalent — @Install(to = "ordersDataGrid.createAction", subject = "viewConfigurer") on a list_create action — is not mentioned: neither that it exists nor when it runs.
What happened
A viewConfigurer was installed on a list_create action with no openMode. It compiles, clean test passes, the view opens with no error — and the handler is never invoked. Without openMode the action navigates, and ActionViewInitializer.initNavigator carries over only viewClass, viewId, routeParameters and queryParameters. viewConfigurer, initializer, afterCloseHandler, transformation and newEntitySupplier are applied only in initWindowBuilder, that is with OpenMode.DIALOG.
It surfaced in production: a user saved an Order with a type that does not belong to its department, and the record vanished from that department's list. It could not be corrected from the UI either, because the type combo on the detail view was narrowed by the same non-working handler. Caught from the production log: ActionHandlerValidator logs a WARN at the moment "Create" is clicked, saying the configurer is set but not invoked when navigating. Nothing earlier sees it — not the compiler, static analysis or tests.
Suggested fix
Add a warning: the handlers of a ViewOpeningAction apply only with OpenMode.DIALOG. When the action navigates (the default when openMode is not set), only route and query parameters survive, so state is passed with @Install(subject = "queryParametersProvider") and read in QueryParametersChangeEvent (it arrives in beforeEnter, before ReadyEvent). A small table "what survives which open mode" would close the whole class of mistakes. Also name the ActionHandlerValidator warning as the only signal the defect gives.
Found while following the skill on a Jmix 2.8.2 project.
Problem: silent — the skill covers passing state into a detail view only through
DialogWindows, and says nothing about the declarative handlers or the open mode they depend on.Task
An
Orderlist view is reused in three departments. A newOrdercreated from a department must receive that department before the detail view builds itsOrderTypecombo box, so the combo offers only the types allowed there.Where
The "Create Child Entity From Selected Master" step passes state with
DialogWindows.detail(...).withInitializer(...). The declarative equivalent —@Install(to = "ordersDataGrid.createAction", subject = "viewConfigurer")on alist_createaction — is not mentioned: neither that it exists nor when it runs.What happened
A
viewConfigurerwas installed on alist_createaction with noopenMode. It compiles,clean testpasses, the view opens with no error — and the handler is never invoked. WithoutopenModethe action navigates, andActionViewInitializer.initNavigatorcarries over onlyviewClass,viewId,routeParametersandqueryParameters.viewConfigurer,initializer,afterCloseHandler,transformationandnewEntitySupplierare applied only ininitWindowBuilder, that is withOpenMode.DIALOG.It surfaced in production: a user saved an
Orderwith a type that does not belong to its department, and the record vanished from that department's list. It could not be corrected from the UI either, because the type combo on the detail view was narrowed by the same non-working handler. Caught from the production log:ActionHandlerValidatorlogs a WARN at the moment "Create" is clicked, saying the configurer is set but not invoked when navigating. Nothing earlier sees it — not the compiler, static analysis or tests.Suggested fix
Add a warning: the handlers of a
ViewOpeningActionapply only withOpenMode.DIALOG. When the action navigates (the default whenopenModeis not set), only route and query parameters survive, so state is passed with@Install(subject = "queryParametersProvider")and read inQueryParametersChangeEvent(it arrives inbeforeEnter, beforeReadyEvent). A small table "what survives which open mode" would close the whole class of mistakes. Also name theActionHandlerValidatorwarning as the only signal the defect gives.