feature request #7887
closedUse DTOs in term editor
100%
Related issues
Updated by Patrick Plitzner about 5 years ago
- Related to feature request #7875: Add multiple area selection to descriptive data set editor added
Updated by Katja Luther about 5 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
Updated by Patrick Plitzner about 5 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.
Updated by Katja Luther about 5 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
Updated by Katja Luther about 5 years ago
- Assignee changed from Katja Luther to Patrick Plitzner
Updated by Patrick Plitzner about 5 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
Updated by Patrick Plitzner about 5 years ago
- Related to bug #7649: Term editor loads/saves extremely slow added
Updated by Patrick Plitzner about 5 years ago
@Katja: Please also check and close #7649 when this is reviewed.
Updated by Patrick Plitzner about 5 years ago
- Related to bug #7367: Deleting a term in the term editor does not update the UI added
Updated by Patrick Plitzner about 5 years ago
- Related to bug #6952: Deleting terms does not get reflected in the UI and in the DB added
Updated by Patrick Plitzner about 5 years ago
- Related to bug #6951: Drag and drop does not update term hierarchy in the UI added
Updated by Katja Luther almost 5 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.
Updated by Andreas Müller almost 5 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.
Updated by Andreas Müller almost 5 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.
Updated by Andreas Müller almost 5 years ago
- Related to bug #7850: Further problems with term editor added
Updated by Andreas Müller almost 5 years ago
- Related to deleted (bug #7850: Further problems with term editor)
Updated by Andreas Müller almost 5 years ago
- Has duplicate bug #7850: Further problems with term editor added
Updated by Patrick Plitzner almost 5 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
Updated by Patrick Plitzner almost 5 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
Updated by Andreas Müller almost 5 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
Updated by Patrick Plitzner almost 5 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
Updated by Andreas Müller almost 5 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.
Updated by Andreas Müller almost 5 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.
Updated by Patrick Plitzner almost 5 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.
Updated by Andreas Müller almost 5 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.
Updated by Andreas Müller almost 5 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.
Updated by Patrick Plitzner almost 5 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.
Updated by Patrick Plitzner almost 5 years ago
- Related to feature request #8067: Remove immediate saving after operations from term editor added