Thanks, Dan
On 09/11/2017 09:00 AM, Dan Haywood wrote:
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
