Module list and user menu is not reloaded when installing new module
When installing a new module on sao, the reload menu action is not updated.
Activity
assigned to @pokoli
added sao type::behavior + 1 deleted label
In fact, the problem is due to [1], which returns a jQuery object that does not have any reference to screen, so the view is not related nor the client actions are executed.
[1] http://hg.tryton.org/sao/file/tip/src/wizard.js#l249unassigned @pokoli
assigned to @pokoli
New review28521002 at https://codereview.tryton.org/28521002/#ps1
review28521002 updated at https://codereview.tryton.org/28521002/#ps20001
msg27043 is not clear about what is happening.
What jQuery object?
Are you sure you are not testing with the patch of #5700 (closed)review28521002 updated at https://codereview.tryton.org/28521002/#ps40001
> Cédric Krier<cedric.krier@b2ck.com> added the comment:
>
> msg27043 is not clear about what is happening.
> What jQuery object?
> Are you sure you are not testing with the patch of #5700 (closed)
No I'm not testing with #5700 (closed). I will rephrase the explanation:
THe problem is that the code is searching for a parent. dialog before the current is closed, as it's an async operation. So we have to wait until the current dialog is closed to search for the parent one.On 2016-07-14 10:27, Sergi Almacellas Abellana wrote:
> THe problem is that the code is searching for a parent. dialog before the current is closed, as it's an async operation. So we have to wait until the current dialog is closed to search for the parent one.
This does not make sense for me. The parent is created before the
children so it must be there.> Cédric Krier<cedric.krier@b2ck.com> added the comment:
>
> On 2016-07-14 10:27, Sergi Almacellas Abellana wrote:
>> >THe problem is that the code is searching for a parent. dialog before the current is closed, as it's an async operation. So we have to wait until the current dialog is closed to search for the parent one.
> This does not make sense for me. The parent is created before the
> children so it must be there.
But the code is filtering on visible, so although it is there it's still visible, so it's now picking the correct dialog. That's why we must wait until the event it's triggered and then it's not visible.On 2016-07-14 10:57, Sergi Almacellas Abellana wrote:
>
> Sergi Almacellas Abellana <sergi@koolpi.com> added the comment:
>
> > Cédric Krier<cedric.krier@b2ck.com> added the comment:
> >
> > On 2016-07-14 10:27, Sergi Almacellas Abellana wrote:
> >> >THe problem is that the code is searching for a parent. dialog before the current is closed, as it's an async operation. So we have to wait until the current dialog is closed to search for the parent one.
> > This does not make sense for me. The parent is created before the
> > children so it must be there.
>
> But the code is filtering on visible, so although it is there it's still visible, so it's now picking the correct dialog. That's why we must wait until the event it's triggered and then it's not visible.
So we could also take the second one?> Cédric Krier<cedric.krier@b2ck.com> added the comment:
>
> On 2016-07-14 10:57, Sergi Almacellas Abellana wrote:
>> >
>> >Sergi Almacellas Abellana<sergi@koolpi.com> added the comment:
>> >
>>> > >Cédric Krier<cedric.krier@b2ck.com> added the comment:
>>> > >
>>> > >On 2016-07-14 10:27, Sergi Almacellas Abellana wrote:
>>>>> > >> >THe problem is that the code is searching for a parent. dialog before the current is closed, as it's an async operation. So we have to wait until the current dialog is closed to search for the parent one.
>>> > >This does not make sense for me. The parent is created before the
>>> > >children so it must be there.
>> >
>> >But the code is filtering on visible, so although it is there it's still visible, so it's now picking the correct dialog. That's why we must wait until the event it's triggered and then it's not visible.
> So we could also take the second one?
No as it only takes the first visible one.New changeset cf2451b293e6 by Sergi Almacellas Abellana in branch 'default':
Fix WizardDialog.destroy
http://hg.tryton.org/sao/rev/cf2451b293e6New changeset 00b07a8edba6 by Sergi Almacellas Abellana in branch '4.0':
Fix WizardDialog.destroy
http://hg.tryton.org/sao/rev/00b07a8edba6
New changeset 096e7a703243 by Sergi Almacellas Abellana in branch '3.8':
Fix WizardDialog.destroy
http://hg.tryton.org/sao/rev/096e7a703243mentioned in issue #5706 (closed)
