bug #10186
closedProblems with session handling in taxeditor
60%
Description
This ticket should contain everything done/tested to fix the session handling problems in the editor, like unsaved changes in typedesignations, secundum references or somewhere else (see related tickets)
Related issues
Updated by Katja Luther almost 2 years ago
- Related to bug #10111: Data loss e.g. when entering type information added
Updated by Katja Luther almost 2 years ago
- Related to bug #10138: Details view is not updated after freetext change added
Updated by Katja Luther almost 2 years ago
- Related to bug #10054: Changes on secundum reference are lost after changing status to basionym added
Updated by Katja Luther almost 2 years ago
- Related to bug #10053: Problems with saving of secundum references added
Updated by Katja Luther almost 2 years ago
- Status changed from New to In Progress
Explaining the already cleaned up code:
SetSelection in setFocus of TaxonNameEditorE4 is not necessary and yields to a second call of the same method (TaxonNameEditorE4.setFocus()).
The TermComboboxes are filled with the terms defined by the preferences or with the whole list of terms of the related type. For the reduced list, the find-call is done with a list of uuids and results alyways in a service call because in cacheTerms only listByTermType is handled.
Therefore the call of TermManager.getTerms(List, TermType) is changed in a way the terms are loaded from the TermStore and then filtered. Maybe this handling can still be improved in any way. But actually the DB calls are reduced and the correct terms are shown also after changing the preference.
The conversationHolder is a leftover from the times before remoting, so we removed it. Actually only a conversation mock was used.
Updated by Andreas Müller almost 2 years ago
- Related to task #10187: Use only 1 service call to initialize supplemental data added
Updated by Andreas Müller almost 2 years ago
A critical issue: In AbstractCdmEditorPartE4 line 182 it is checked if (new) selection equals the previous selection. But this does not take into account that the selection may still change in an already added "sync.asyncExec(delaySelection);" call which is in the pipeline. So the latest focus/selection change may be swollowed by this check, however, the focus may be in the new position while the selection in the view-to-be-updated may later change to the selection previously selected and asynchronously called.
This is only the case when setting the focus back and forth between 2 different selections.
Updated by Andreas Müller over 1 year ago
- % Done changed from 0 to 20
Andreas Müller wrote in #note-7:
A critical issue: In AbstractCdmEditorPartE4 line 182 it is checked if (new) selection equals the previous selection. But this does not take into account that the selection may still change in an already added "sync.asyncExec(delaySelection);" call which is in the pipeline. So the latest focus/selection change may be swollowed by this check, however, the focus may be in the new position while the selection in the view-to-be-updated may later change to the selection previously selected and asynchronously called.
This is only the case when setting the focus back and forth between 2 different selections.
This should be fixed now with dad85080 and 20d52c89 . The result looks as far as now the focus and the selected data in the views seems to be always the same if one waits until the views have all loaded, even if you clicked before multiple times on different selections. However, it still needs intensive testing before being released.
Updated by Andreas Müller over 1 year ago
- Related to bug #7699: NPE in CdmTransientEntityCacher.getCacheElement() added
Updated by Andreas Müller over 1 year ago
Katja Luther wrote in #note-5:
SetSelection in setFocus of TaxonNameEditorE4 is not necessary and yields to a second call of the same method (TaxonNameEditorE4.setFocus()).
Does this need to be fixed also in other Editors like Term Editor?
Updated by Andreas Müller over 1 year ago
- Related to bug #10214: Cache configuration for term cache not correctly initialized in taxeditor added
Updated by Katja Luther over 1 year ago
Andreas Müller wrote in #note-10:
Katja Luther wrote in #note-5:
SetSelection in setFocus of TaxonNameEditorE4 is not necessary and yields to a second call of the same method (TaxonNameEditorE4.setFocus()).
Does this need to be fixed also in other Editors like Term Editor?
In setFocus of termEditor there is no setSelected call also in Bulkeditor, DescriptiveDatasetEditor and others. This was a special case because of the containers of the taxon editor
Updated by Andreas Müller over 1 year ago
- Related to bug #8953: Focus not correctly evaluated for details view when switching between names added
Updated by Andreas Müller over 1 year ago
- Related to bug #10068: Changing focus to accepted taxon does not work added
Updated by Andreas Müller over 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 20 to 60
Should we close this ticket and open a new one if we do further research on taxeditor sessions? I think there are a couple of issues that were fixed within this ticket or in related tickets opened during research.
Updated by Katja Luther over 1 year ago
- Status changed from Resolved to Closed
Further issues can be handled in the more detailed tickets.
Updated by Andreas Müller over 1 year ago
- Related to feature request #6554: The details views are newly created with every change of the focus added