FYI, this is fixed in master branch. Cheers, Dan On Wed, 6 Sep 2017, 15:00 Dan Haywood <[email protected]> wrote:
> 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 <[email protected]> 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 >> >
