Project

General

Profile

Actions

bug #10138

closed

Details view is not updated after freetext change

Added by Katja Luther 5 months ago. Updated about 1 month ago.

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

100%

Estimated time:
Severity:
critical
Found in Version:

Description

... which may lead to data loss.

WGB:

Fl. Cuba; ich habe eben 2 Synonyme eingegeben, und zwar folgendermaßen:
Antidesma rosaurianum (‘rosariana’) M. Gómez
Antidesma rosariana M. Gómez
gepasted und Save

Die beiden standen normal in der Synonymliste, kein * im Tag, Save-Button nicht aktiv.

Dann wollte ich die 2. als original spelling auswählen und fand sie nicht in der Liste.
Nach einigem Hin und Her dann das Taxon neu aufgerufen: Die Synonyme waren weg.

Ich versuche das jetzt nochmal.

====

ich habe das nochmal genau so gemacht:

Falscher Eintrag (mit original spelling) – im Taxon Editor das (‚rosariana‘) gelöscht. Und gespeichert.

Dann die Referenz eingetragen (ich weiß nicht, ob letztes mal der Cache im Details View noch den alten Eintrag zeigte. Und auch gleich das original spelling versucht einzutragen – war jetzt in der Namensliste vorhanden.

ABER: Trotz Save wird der Name nicht in den Taxon Editor übertragen („as ...“)

Taxon mit doppelklick im Navigator aufgerufen – die letzten Einträge sind weg:

Dann alles neu eingetragen, alles gut. Scheinbar.

Beim Löschen des Synonyms wurde ich nicht auf das nicht-Namens-löschen hingewiesen.
Der orginal name wurde gelöscht
Das sieht jetzt so aus:

Referenz ist auch weg.


Files

eins.png (12.4 KB) eins.png Katja Luther, 09/07/2022 10:10 AM
drei.png (45.1 KB) drei.png Katja Luther, 09/07/2022 10:10 AM
vier.jpg (65.3 KB) vier.jpg Katja Luther, 09/07/2022 10:10 AM
fuenf.png (56.7 KB) fuenf.png Katja Luther, 09/07/2022 10:10 AM
zwei.png (19 KB) zwei.png Katja Luther, 09/07/2022 10:10 AM

Related issues

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

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 - bug #10186: Problems with session handling in taxeditorClosedKatja Luther

Actions
Related to EDIT - bug #10219: Setting the focus to an already selected entity should not refresh the details viewNewKatja 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
Has duplicate EDIT - bug #8590: Details view does not show data of new synonymDuplicateAndreas Müller

Actions
Actions #1

Updated by Katja Luther 5 months ago

  • Severity changed from normal to critical
Actions #2

Updated by Katja Luther 5 months ago

  • Status changed from New to In Progress

The issue about the nameUsedInSource seems to be a problem of the parser, at the beginning of the parsing all elements are set to null (in makeEmpty(INonViralName name)), if the string can not be parsed, author and nomenclatural reference and nameUsedInSource are still empty and will be saved like this.

Actions #3

Updated by Andreas Müller 5 months ago

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

Updated by Andreas Müller 5 months ago

Maybe related to #10111

Actions #5

Updated by Andreas Müller 5 months ago

  • Status changed from In Progress to Feedback
  • Assignee changed from Katja Luther to Andreas Müller
Actions #6

Updated by Andreas Müller 5 months ago

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

Updated by Andreas Müller 5 months ago

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

Updated by Andreas Müller 5 months ago

  • Description updated (diff)
Actions #9

Updated by Andreas Müller 5 months ago

  • Status changed from Feedback to Discussed
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 0 to 10

Katja Luther wrote in #note-2:

The issue about the nameUsedInSource seems to be a problem of the parser, at the beginning of the parsing all elements are set to null (in makeEmpty(INonViralName name)), if the string can not be parsed, author and nomenclatural reference and nameUsedInSource are still empty and will be saved like this.

No, this is not the issue here. Fully emptying the name before parsing is wanted behavior.

The problem is the way how the TaxEditor refreshes the DetailsView after changes in the freetext area. The details view is only updated after the freetext record lost focus. This is partly wanted as we do not want to run parsing after each text change as parsing (and related deduplication) is a costly serverside function.
However, what is needed here is to not allow editing the details view after changes have been done in the freetext area and the focus is still on the record that has been changed .

In concrete, what happened here is, that originally the name had a protected namecache and this information still existed in the details view representation. Therefore changing the nom.source+original name had no effect in the freetext area.

Actions #10

Updated by Andreas Müller 5 months ago

  • Subject changed from Synonyms are deleted to Details view is not updated after freetext change
  • Description updated (diff)
Actions #11

Updated by Andreas Müller 4 months ago

  • Target version changed from Release 5.33 to Release 5.35
Actions #12

Updated by Katja Luther 3 months ago

  • Related to bug #10186: Problems with session handling in taxeditor added
Actions #13

Updated by Andreas Müller about 2 months ago

  • Status changed from Discussed to Feedback
  • % Done changed from 10 to 60

This is probably fixed but not yet commited.

Actions #14

Updated by Katja Luther about 2 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 60 to 10

this should be fixed, please review.

Actions #15

Updated by Andreas Müller about 2 months ago

  • Assignee changed from Katja Luther to Andreas Müller
  • % Done changed from 10 to 70
Actions #16

Updated by Andreas Müller about 2 months ago

As far as I can see the event throwing not happens additionally to the event thrown by selection change. We need to check if this results in a duplicated details view building or if the second build is filtered out somehow. Additionally the REFRESH_DETAILS line seems to be called 2x so maybe alltogehter DetailsView is build 3x. This needs to be checked before going to production therefore I reverted this line (94fccb8a).

Actions #17

Updated by Andreas Müller about 2 months ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 70 to 50

Can you please check this in detail.

Actions #18

Updated by Katja Luther about 2 months ago

  • Status changed from Feedback to In Progress

Andreas Müller wrote in #note-16:

As far as I can see the event throwing not happens additionally to the event thrown by selection change. We need to check if this results in a duplicated details view building or if the second build is filtered out somehow. Additionally the REFRESH_DETAILS line seems to be called 2x so maybe alltogehter DetailsView is build 3x. This needs to be checked before going to production therefore I reverted this line (94fccb8a).

This problem appears if the selected view is for example the empty media view, but not if the selection changes to the details or supplemental data view.

Actions #19

Updated by Andreas Müller about 2 months ago

Katja Luther wrote in #note-18:

Andreas Müller wrote in #note-16:

As far as I can see the event throwing not happens additionally to the event thrown by selection change. We need to check if this results in a duplicated details view building or if the second build is filtered out somehow. Additionally the REFRESH_DETAILS line seems to be called 2x so maybe alltogehter DetailsView is build 3x. This needs to be checked before going to production therefore I reverted this line (94fccb8a).

This problem appears if the selected view is for example the empty media view, but not if the selection changes to the details or supplemental data view.

But it also happens when selecting another name in the synonymy. So generally it is maybe not a good idea to refresh the details view after a focus loss because there is no need to refresh as long as the new focus does not need the exact same input. The refresh should take place when the new focus has the same input as the old one but data in the old one has changed which is generally not the case - but some cases exist like the one mentioned in the ticket description.
I think we discussed it the way, that the details view (and maybe others) should be disabled once a change in freetext took place. By clicking on the details view the new data should be build/inserted.

Additionally we could implement a time triggered parsing after e.g. 3s of no change. The parsing will then also update views.

Actions #20

Updated by Andreas Müller about 1 month ago

  • Status changed from In Progress to Feedback

This needs to be reverted or adapted. Currently the detail view very often refreshes. This happens also in many cases when it is not necessary.

E.g.

  • changing focus to other synonym in TaxonEditor refreshes the DetailsView 2x(!), first with the old data, then with the new data
  • changing to focus from synonym to details view or supplementalDataView refreshes the DetailsView if if no data has changed (no parsing) which is not necessary
  • changing back from DetailsView or SupplementalDataView to Taxon Editor again refreshes the DetailsView although not necessary

This really slows the TaxEditor in its core functionality.
The reason for the behavior is the above mentioned conceptual mistake.
It does not make sense to refresh DetailsView for any data that looses the focus! You need to refresh the View once you know what the new focus is.

So the general rule should be:

  • Keep everything as in previous versions
  • ONLY if the details view gets the focus AND if a name in the TaxEditor had the focus before AND if the name has been parsed due to changes in freetext THEN refresh the DetailsView.
Actions #21

Updated by Katja Luther about 1 month ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Katja Luther to Andreas Müller

The new solution disables the details view after editing the name in name editor, editing the other names/taxon/synonyms still possible and after loosing the focus and get it back to the edited name, the details are enabled again because they are refreshed. Please have a look whether this is a better solution.

Actions #22

Updated by Katja Luther about 1 month ago

I just tried out another implementation: now the detailsviewer just remember that there are changes in Name Editor and if it gets the focus the details view refreshes. If there are no changes, the details view is not updated.

Actions #23

Updated by Andreas Müller about 1 month ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther

Katja Luther wrote in #note-21:

The new solution disables the details view after editing the name in name editor, editing the other names/taxon/synonyms still possible and after loosing the focus and get it back to the edited name, the details are enabled again because they are refreshed. Please have a look whether this is a better solution.

It is much better now. There are just a few improvements that could make work even more comfortable. Currently the disabling is not yet removed in many cases but it should. E.g. clicking on FactualData View, Media View or SupplementalData View and maybe others should also enable (and recompute) the DetailsView again. Also clicking on the DetailsView itself I would expect reenables the DetailsView and immediately recomputes it but I don't know how far this is easy to implement.

Actions #24

Updated by Andreas Müller about 1 month ago

Katja Luther wrote in #note-22:

I just tried out another implementation: now the detailsviewer just remember that there are changes in Name Editor and if it gets the focus the details view refreshes. If there are no changes, the details view is not updated.

This sounds like the best solution if it works as described.

Actions #25

Updated by Andreas Müller about 1 month ago

  • % Done changed from 50 to 70

Andreas Müller wrote in #note-24:

Katja Luther wrote in #note-22:

I just tried out another implementation: now the detailsviewer just remember that there are changes in Name Editor and if it gets the focus the details view refreshes. If there are no changes, the details view is not updated.

This sounds like the best solution if it works as described.

I tested a bit and it works fully correct. There are only 3 minor issues that might be discussed.

  1. If I go to the DetailsView (after freetext change) it updates which is correct, if I go back to the freetext it updates again which is not necessary - hmm, tested and this is also the case without freetext change. So maybe it is another ticket, but if it is easy to fix we may do it now

  2. if clicking on the Fact, Media or SupplView the Details View does not refresh though there was change via freetext. One may discuss that this is wanted behavior as refresh slows down performance but IMO we should refresh as fast as possible once parsing was done.

  3. I did like the disabling to indicate that data is not valid anymore so can we keep the disabling and simply do enabling when the view is refreshed.

All these 3 are minor issues and should be implemented in current version only if they are no-brainers and not dangerous to brake anything.

Actions #26

Updated by Katja Luther about 1 month ago

Andreas Müller wrote in #note-25:

Andreas Müller wrote in #note-24:

Katja Luther wrote in #note-22:

I just tried out another implementation: now the detailsviewer just remember that there are changes in Name Editor and if it gets the focus the details view refreshes. If there are no changes, the details view is not updated.

This sounds like the best solution if it works as described.

I tested a bit and it works fully correct. There are only 3 minor issues that might be discussed.

  1. If I go to the DetailsView (after freetext change) it updates which is correct, if I go back to the freetext it updates again which is not necessary - hmm, tested and this is also the case without freetext change. So maybe it is another ticket, but if it is easy to fix we may do it now

This is like it was before, I think there is already a ticket about it. (for example #6554, but this is not for this concrete issue)

  1. if clicking on the Fact, Media or SupplView the Details View does not refresh though there was change via freetext. One may discuss that this is wanted behavior as refresh slows down performance but IMO we should refresh as fast as possible once parsing was done.

In most cases, clicking on the factual data view enables the details of the selected item, otherwise the change would be available if the user changes the focus again to the details view or the name editor.

  1. I did like the disabling to indicate that data is not valid anymore so can we keep the disabling and simply do enabling when the view is refreshed.

This can be enabled with one line, I added again.

All these 3 are minor issues and should be implemented in current version only if they are no-brainers and not dangerous to brake anything.

The disabling is added again and the issue about the focus of the factual data, media or supplemental data view can be handled in another ticket, so I would close this ticket. Do you want to have a final view?

Actions #27

Updated by Katja Luther about 1 month ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Katja Luther to Andreas Müller
Actions #28

Updated by Andreas Müller about 1 month ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 70 to 90

Katja Luther wrote in #note-26:

This is like it was before, I think there is already a ticket about it. (for example #6554, but this is not for this concrete issue)

OK, so if it is not straight forward to implement we leave it for later but we should check if there is really a ticket for it (#6554 is about something else). It is actually true for the supplemental data view, too, that it often reloads though the data to show is the same. I wonder about this because at other places we check if the input is the same and do not recompute. Do you know where in the code this happens?

  1. if clicking on the Fact, Media or SupplView the Details View does not refresh though there was change via freetext. One may discuss that this is wanted behavior as refresh slows down performance but IMO we should refresh as fast as possible once parsing was done.

In most cases, clicking on the factual data view enables the details of the selected item, otherwise the change would be available if the user changes the focus again to the details view or the name editor.

Ok, so we leave it. I was mostly working in synonymies, there Facts and Media are always empty so clicking on them was an easy way to trigger reload (which actually happens for the SupplementalDataView where it is unwanted - Suppl Data don't change by parsing)

  1. I did like the disabling to indicate that data is not valid anymore so can we keep the disabling and simply do enabling when the view is refreshed.

This can be enabled with one line, I added again.

Works fine

The disabling is added again and the issue about the focus of the factual data, media or supplemental data view can be handled in another ticket, so I would close this ticket. Do you want to have a final view?

So we can close this ticket but should open new tickets for the open issues if they do not exist yet.

Actions #29

Updated by Katja Luther about 1 month ago

  • Related to bug #10219: Setting the focus to an already selected entity should not refresh the details view added
Actions #30

Updated by Katja Luther about 1 month ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100
Actions #31

Updated by Andreas Müller about 1 month ago

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

Updated by Andreas Müller about 1 month ago

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

Updated by Andreas Müller about 1 month ago

  • Has duplicate bug #8590: Details view does not show data of new synonym added
Actions

Also available in: Atom PDF