Project

General

Profile

Actions

feature request #7887

closed

Use DTOs in term editor

Added by Patrick Plitzner about 4 years ago. Updated almost 4 years ago.

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

100%

Estimated time:
Severity:
normal

Related issues

Related to EDIT - feature request #7875: Add multiple area selection to descriptive data set editorClosedPatrick Plitzner

Actions
Related to EDIT - bug #7649: Term editor loads/saves extremely slowClosedPatrick Plitzner

Actions
Related to EDIT - bug #7367: Deleting a term in the term editor does not update the UIClosedPatrick Plitzner

Actions
Related to EDIT - bug #6952: Deleting terms does not get reflected in the UI and in the DBIn ProgressKatja Luther

Actions
Related to EDIT - bug #6951: Drag and drop does not update term hierarchy in the UIClosedPatrick Plitzner

Actions
Related to EDIT - feature request #8067: Remove immediate saving after operations from term editorNewKatja Luther

Actions
Has duplicate EDIT - bug #7850: Further problems with term editorDuplicatePatrick Plitzner

Actions
Actions #1

Updated by Patrick Plitzner about 4 years ago

Actions #2

Updated by Katja Luther about 4 years ago

some issues I recognized while testing:

  • the details view updates with every keystroke
  • sometimes saving takes really long
  • after creating a new vocabulary the editor does not update, you have to reopen the editor to see the new vocabulary
Actions #3

Updated by Patrick Plitzner about 4 years ago

  • Status changed from New to Resolved
  • Assignee changed from Patrick Plitzner to Katja Luther
  • Target version changed from Unassigned CDM tickets to Release 5.5
  • % Done changed from 0 to 50

Katja Luther wrote:

some issues I recognized while testing:

  • after creating a new vocabulary the editor does not update, you have to reopen the editor to see the new vocabulary

I fixed the refresh problem for new vocabularies.

  • the details view updates with every keystroke

Do you mean keystrokes in the details view? I don't see such behavior but it may depend on the hardware.

  • sometimes saving takes really long

This should also be fixed. It used to save the same element multiple times.

Actions #4

Updated by Katja Luther about 4 years ago

  • Status changed from Resolved to Closed

looks fine now!

Actions #5

Updated by Katja Luther about 4 years ago

  • Status changed from Closed to Feedback

One open issue:

when creating a new defined term, the selection is still on the vocabulary, for lists with several entries, it is difficult to find the new term

Actions #6

Updated by Katja Luther about 4 years ago

  • Assignee changed from Katja Luther to Patrick Plitzner
Actions #7

Updated by Patrick Plitzner about 4 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Patrick Plitzner to Katja Luther

Katja Luther wrote:

One open issue:

when creating a new defined term, the selection is still on the vocabulary, for lists with several entries, it is difficult to find the new term

This should be fixed now

Actions #8

Updated by Patrick Plitzner about 4 years ago

  • Related to bug #7649: Term editor loads/saves extremely slow added
Actions #9

Updated by Patrick Plitzner about 4 years ago

@Katja: Please also check and close #7649 when this is reviewed.

Actions #10

Updated by Patrick Plitzner about 4 years ago

  • Related to bug #7367: Deleting a term in the term editor does not update the UI added
Actions #11

Updated by Patrick Plitzner about 4 years ago

  • Related to bug #6952: Deleting terms does not get reflected in the UI and in the DB added
Actions #12

Updated by Patrick Plitzner about 4 years ago

  • Related to bug #6951: Drag and drop does not update term hierarchy in the UI added
Actions #13

Updated by Katja Luther almost 4 years ago

  • Status changed from Resolved to Closed
  • Assignee changed from Katja Luther to Patrick Plitzner
  • % Done changed from 50 to 100

after creating a new namedArea the deletion does not work because it is referenced by its parent. This is fixed with revision c5802825b

everything else seems to work fine.

Actions #14

Updated by Andreas Müller almost 4 years ago

  • Status changed from Closed to Feedback
  • % Done changed from 100 to 50

Ein Problem ... ist, dass wenn ich ein Area mit mind. 1 Kind habe, und dieses Area dann zu einem Kind von sich selbst mache (schiebe) versehentlich, dann verschwindet der Term gänzlich samt aller Kinder. IN der DB ist das dann als Kind von sich selbst gespeichert. Ein solcher Drop sollte möglichst gar nicht erlaubt sein.

Actions #15

Updated by Andreas Müller almost 4 years ago

… und wenn ich einen Term auf Top Level oberhalb eines Vokabulars versuche zu schieben wird er an die letzte Position dieses Vokabulars geschoben. Wenn dann würde es Sinn machen ihn an die letzte Position des darüber liegenden Vokabulars zu schieben, am besten wäre es aber, ein drop auf Toplevel (also im Prinzip auf Vokabularebene) überhaupt nicht zuzulassen.

Actions #16

Updated by Andreas Müller almost 4 years ago

  • Related to bug #7850: Further problems with term editor added
Actions #17

Updated by Andreas Müller almost 4 years ago

  • Related to deleted (bug #7850: Further problems with term editor)
Actions #18

Updated by Andreas Müller almost 4 years ago

  • Has duplicate bug #7850: Further problems with term editor added
Actions #19

Updated by Patrick Plitzner almost 4 years ago

Andreas Müller wrote:

Ein Problem ... ist, dass wenn ich ein Area mit mind. 1 Kind habe, und dieses Area dann zu einem Kind von sich selbst mache (schiebe) versehentlich, dann verschwindet der Term gänzlich samt aller Kinder. IN der DB ist das dann als Kind von sich selbst gespeichert. Ein solcher Drop sollte möglichst gar nicht erlaubt sein.

this is fixed now

Actions #20

Updated by Patrick Plitzner almost 4 years ago

  • Assignee changed from Patrick Plitzner to Andreas Müller
  • % Done changed from 50 to 60

Andreas Müller wrote:

… und wenn ich einen Term auf Top Level oberhalb eines Vokabulars versuche zu schieben wird er an die letzte Position dieses Vokabulars geschoben. Wenn dann würde es Sinn machen ihn an die letzte Position des darüber liegenden Vokabulars zu schieben, am besten wäre es aber, ein drop auf Toplevel (also im Prinzip auf Vokabularebene) überhaupt nicht zuzulassen.

We have to allow dropping onto vocabularies in order to either move a term from one vocabulary to another or to move it from a lower level to the top level of its vocabulary

Actions #21

Updated by Andreas Müller almost 4 years ago

  • Assignee changed from Andreas Müller to Patrick Plitzner

Patrick Plitzner wrote:

Andreas Müller wrote:

… und wenn ich einen Term auf Top Level oberhalb eines Vokabulars versuche zu schieben wird er an die letzte Position dieses Vokabulars geschoben. Wenn dann würde es Sinn machen ihn an die letzte Position des darüber liegenden Vokabulars zu schieben, am besten wäre es aber, ein drop auf Toplevel (also im Prinzip auf Vokabularebene) überhaupt nicht zuzulassen.

We have to allow dropping onto vocabularies in order to either move a term from one vocabulary to another or to move it from a lower level to the top level of its vocabulary

yes, but I drop it above the vocabulary, this should not result in adding it to the vocabulary, but, if at all to the above vocabulary

Actions #22

Updated by Patrick Plitzner almost 4 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Patrick Plitzner to Andreas Müller
  • % Done changed from 60 to 80

Terms cannot be dropped above or below TermVocabulary any more

Actions #23

Updated by Andreas Müller almost 4 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Patrick Plitzner
  • % Done changed from 80 to 60

Patrick Plitzner wrote:

Terms cannot be dropped above or below TermVocabulary any more

This seems to work now.

Actions #24

Updated by Andreas Müller almost 4 years ago

Ordering does not seem to work anymore. I tested with a user defined named area vocabulary with 7 no hiearchical areas.

I tried to move an area but nothing happened in UI. Also not after reopening Term Editor and also not after TaxEditor restart. Though something changed in NamedArea.orderindex in DB. But this also looks corrupted. E.g. after a while orderindex 0 did not exist anymore. Maybe the later also might be a cdmlib issue.

This is an important issue but we have to have in mind that ordering will be handled differently in future cdmlib versions so only simple fixes should be implemented.

Actions #25

Updated by Patrick Plitzner almost 4 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Patrick Plitzner to Andreas Müller

Andreas Müller wrote:

Ordering does not seem to work anymore. I tested with a user defined named area vocabulary with 7 no hiearchical areas.

I tried to move an area but nothing happened in UI. Also not after reopening Term Editor and also not after TaxEditor restart. Though something changed in NamedArea.orderindex in DB. But this also looks corrupted. E.g. after a while orderindex 0 did not exist anymore. Maybe the later also might be a cdmlib issue.

This is an important issue but we have to have in mind that ordering will be handled differently in future cdmlib versions so only simple fixes should be implemented.

This is fixed now. I forgot to return the order index when fixing another sorting issue.

Actions #26

Updated by Andreas Müller almost 4 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Patrick Plitzner
  • % Done changed from 60 to 80

Patrick Plitzner wrote:

Andreas Müller wrote:

Ordering does not seem to work anymore. I tested with a user defined named area vocabulary with 7 no hiearchical areas.

I tried to move an area but nothing happened in UI. Also not after reopening Term Editor and also not after TaxEditor restart. Though something changed in NamedArea.orderindex in DB. But this also looks corrupted. E.g. after a while orderindex 0 did not exist anymore. Maybe the later also might be a cdmlib issue.

This is an important issue but we have to have in mind that ordering will be handled differently in future cdmlib versions so only simple fixes should be implemented.

This is fixed now. I forgot to return the order index when fixing another sorting issue.

It seems to work now in user interface. Still the orderIndex in the DB does have missing number in between if moving back and forth in the UI. This might be a cdmlib issue. As ordering will be changed in future anyway this is not considered to be critical.

Actions #27

Updated by Andreas Müller almost 4 years ago

Are there still open issues that need to be handled in separate tickets? I remember you said that vocabularies do not yet use DTOs. Is this fixed or does an other ticket exist? Please link if the later is true.

Also we decided that immediate saving for moving or deleting should be removed. This requires a new ticket but I can't see a link. Please create new ticket or link to existing ticket.

Afterwards this ticket can be closed.

Actions #28

Updated by Patrick Plitzner almost 4 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 80 to 100

Andreas Müller wrote:

Are there still open issues that need to be handled in separate tickets? I remember you said that vocabularies do not yet use DTOs. Is this fixed or does an other ticket exist? Please link if the later is true.

Also we decided that immediate saving for moving or deleting should be removed. This requires a new ticket but I can't see a link. Please create new ticket or link to existing ticket.

Afterwards this ticket can be closed.

Added a new ticket for saving -> #8067

I was wrong, the term editor already works with DTOs for term vocabularies.

Actions #29

Updated by Patrick Plitzner almost 4 years ago

Actions

Also available in: Atom PDF