EDIT

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.

looks fine now!

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

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

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.

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.

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

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

Terms cannot be dropped above or below TermVocabulary any more

Patrick Plitzner wrote:

Terms cannot be dropped above or below TermVocabulary any more

This seems to work now.

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.

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.

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.