Hi Erik, just encountered this issue with our app as well, in 1.15.0.
As you say, if the choices list returns a set that does not include the value of the field, then the first choice is taken. I think that the correct behaviour is that the value of the field should be shown; the choices only comes into play if the user attempts to change the value. I guess until I sort this out the partial workaround is to programmatically ensure that the choices DOES include the current value. I've raised ISIS-1711 [1] for this As it happens, in 1.15.0 we also upgraded to Wicket 7.8.0, and Wicket are in the process of releasing a Wicket 7.8.1 patch for a serious issue. So I'll push this fix out (when I've done it) in an Isis 1.15.1 release. Thx Dan [1] https://issues.apache.org/jira/browse/ISIS-1711 On Tue, 5 Sep 2017 at 10:32 Erik de Hair <e.deh...@pocos.nl> wrote: > Hi, > > We have a strange case for a subscription's property referencing a > Contact (Apache Isis 1.14.x). > > The database tells me it has a reference to Contact with id 1, but > Contact with id 5 is displayed in the Wicket viewer. So when I ask the > subscription for it's contact programmatically it will return Contact 1 > but the Wicket viewer displays number 5. In this case an email was sent > to the contact as referenced in the database, while a user expected an > email to be sent to the other Contact. > > This happens when Contact number 1 is not present in the choices for > editing the Contact property (probably because of changed business rules > or another system updating the same database). Before [1] the entityLink > has a reference to the right Contact but after [1] it is overwritten by > the first item of the choices. > > It probably depends on the use case what the behaviour should be, but > in this case I expected Contact number 1. The question is: should the > current selected item always be in the list of choices or should it be > ignored if it doesn't comply with the business rules? The last case can > give unexpected behaviour for people clicking the popup away using OK, > without noticing the selected item was different from the item that was > actually set. What happens in this case with inline editing? > > Erik > > [1] > > https://github.com/apache/isis/blob/rel/isis-1.14.0/core/viewer-wicket-ui/src/main/java/org/apache/isis/viewer/wicket/ui/components/scalars/reference/ReferencePanel.java#L128 >
