Project

General

Profile

Actions

bug #10186

closed

Problems with session handling in taxeditor

Added by Katja Luther 2 months ago. Updated 22 days ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

60%

Estimated time:
Severity:
normal
Found in Version:

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

Related to EDIT - bug #10111: Data loss e.g. when entering type informationResolvedAndreas Müller

Actions
Related to EDIT - bug #10138: Details view is not updated after freetext changeClosedKatja Luther

Actions
Related to EDIT - bug #10054: Changes on secundum reference are lost after changing status to basionymResolvedAndreas Müller

Actions
Related to EDIT - bug #10053: Problems with saving of secundum referencesResolvedAndreas Müller

Actions
Related to EDIT - task #10187: Use only 1 service call to initialize supplemental dataNewKatja Luther

Actions
Related to EDIT - bug #7699: NPE in CdmTransientEntityCacher.getCacheElement()In ProgressAndreas Müller

Actions
Related to EDIT - bug #10214: Cache configuration for term cache not correctly initialized in taxeditorResolvedKatja Luther

Actions
Related to EDIT - bug #8953: Focus not correctly evaluated for details view when switching between namesResolvedAndreas Müller

Actions
Related to EDIT - bug #10068: Changing focus to accepted taxon does not workClosedAndreas Müller

Actions
Related to EDIT - feature request #6554: The details views are newly created with every change of the focus In ProgressKatja Luther

Actions
Actions #1

Updated by Katja Luther 2 months ago

  • Related to bug #10111: Data loss e.g. when entering type information added
Actions #2

Updated by Katja Luther 2 months ago

  • Related to bug #10138: Details view is not updated after freetext change added
Actions #3

Updated by Katja Luther 2 months ago

  • Related to bug #10054: Changes on secundum reference are lost after changing status to basionym added
Actions #4

Updated by Katja Luther 2 months ago

  • Related to bug #10053: Problems with saving of secundum references added
Actions #5

Updated by Katja Luther 2 months 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.

Actions #6

Updated by Andreas Müller 2 months ago

  • Related to task #10187: Use only 1 service call to initialize supplemental data added
Actions #7

Updated by Andreas Müller 2 months 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.

Actions #8

Updated by Andreas Müller 2 months 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.

Actions #9

Updated by Andreas Müller about 2 months ago

  • Related to bug #7699: NPE in CdmTransientEntityCacher.getCacheElement() added
Actions #10

Updated by Andreas Müller about 1 month 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?

Actions #11

Updated by Andreas Müller about 1 month ago

  • Related to bug #10214: Cache configuration for term cache not correctly initialized in taxeditor added
Actions #12

Updated by Katja Luther 22 days 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

Actions #13

Updated by Andreas Müller 22 days ago

  • Related to bug #8953: Focus not correctly evaluated for details view when switching between names added
Actions #14

Updated by Andreas Müller 22 days ago

  • Related to bug #10068: Changing focus to accepted taxon does not work added
Actions #15

Updated by Andreas Müller 22 days 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.

Actions #16

Updated by Katja Luther 22 days ago

  • Status changed from Resolved to Closed

Further issues can be handled in the more detailed tickets.

Actions #17

Updated by Andreas Müller 22 days ago

  • Related to feature request #6554: The details views are newly created with every change of the focus added
Actions

Also available in: Atom PDF