Project

General

Profile

feature request #8044

Add "Move to..." menu to term editor

Added by Patrick Plitzner over 1 year ago. Updated 4 months ago.

Status:
Closed
Priority:
Priority13
Assignee:
Category:
taxeditor
Target version:
Start date:
01/31/2019
Due date:
% Done:

100%

Severity:
normal
Tags:

Description

Just like in the taxon navigator it should be possible to move a term to another term which is selected in a dialog.

This is especially important for long, flat term vocabularies which have to be edited.

Maybe we also want Cut&Paste for the term editor.

picture339-2.png View (40.3 KB) Andreas Kohlbecker, 03/18/2020 04:21 PM

picture870-1.png View (13.9 KB) Katja Luther, 03/19/2020 07:15 AM


Related issues

Related to Edit - feature request #8885: Distinguish between terms and vocabularies in term search dialog New 03/09/2020
Duplicated by Edit - bug #8763: Remaining issues for "Move term" in term editor Duplicate 12/11/2019

Associated revisions

Revision 5e339d32 (diff)
Added by Patrick Plitzner over 1 year ago

ref #8044 Add "Move to..." menu to term editor

Revision cf7529d5 (diff)
Added by Patrick Plitzner about 1 year ago

ref #8044 Make "Move to..." experimental

Revision 1626b3d2 (diff)
Added by Katja Luther 5 months ago

ref #8044: add service/persistence method to get vocDto for pattern

Revision 2d38478f (diff)
Added by Katja Luther 5 months ago

ref #8044: search for vocs and do not show selected term

Revision 501ec636 (diff)
Added by Katja Luther 5 months ago

ref #8044: add missing termcollection dto

Revision a57fcfb4 (diff)
Added by Katja Luther 5 months ago

ref #8763: set search button to default

Revision cb827f5e (diff)
Added by Katja Luther 5 months ago

ref #8763: disable multiselect

Revision bac71f46 (diff)
Added by Katja Luther 5 months ago

fix #8044: remove injected method

Revision bc6f4f4e (diff)
Added by Katja Luther 4 months ago

ref #8044: handle update result of moveTerm correctly

Revision ad938fd2 (diff)
Added by Katja Luther 4 months ago

ref #8044: moveTerm return updateResult and voc search is contains search

Revision 29f07c5d (diff)
Added by Katja Luther 4 months ago

fix #8044: focus on search field results in search for enter

History

#1 Updated by Patrick Plitzner over 1 year ago

  • Priority changed from New to Priority13
  • Target version changed from Unassigned CDM tickets to Release 5.6

#2 Updated by Patrick Plitzner about 1 year ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Closing this ticket because it is implemented but still experimental.

#3 Updated by Patrick Plitzner about 1 year ago

  • Status changed from Resolved to Closed

#4 Updated by Andreas Müller about 1 year ago

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

As the term editor is not experimental this feature is also not experimental. Therefore it should be tested for correctness.

#5 Updated by Patrick Plitzner about 1 year ago

The menu item is only shown when experimental features are enabled. Therefore this can be tested later. Also this option uses the new experimental term search functionality. That's why I closed it. This was anyway a feature request that came up in the context of Additivity.

#6 Updated by Katja Luther about 1 year ago

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

I would name it move feature as child or something like this because in the wizard you can choose the parent. Maybe you also should add some more description to the wizard.

#7 Updated by Patrick Plitzner about 1 year ago

This is still an experimental feature which only shows up when the flag is set. I would either move this ticket to the next milestone or just close it and open another issue when this is considered non experimental

#8 Updated by Patrick Plitzner about 1 year ago

  • Target version changed from Release 5.6 to Release 5.7

Moving to 5.7 where it can be reviewed when set to non-experimental

#9 Updated by Patrick Plitzner about 1 year ago

  • Target version changed from Release 5.7 to Release 5.8

#10 Updated by Patrick Plitzner 12 months ago

  • Target version changed from Release 5.8 to Release 5.10

Move to next milestone because this is still considered experimental

#11 Updated by Patrick Plitzner 12 months ago

  • % Done changed from 100 to 90

#12 Updated by Patrick Plitzner 10 months ago

  • Target version changed from Release 5.10 to Release 5.11

#13 Updated by Patrick Plitzner 8 months ago

  • Status changed from Feedback to Resolved
  • Target version changed from Release 5.11 to 287

#14 Updated by Patrick Plitzner 7 months ago

  • Assignee changed from Patrick Plitzner to Andreas Müller

This is not not experimental anymore.

Known issues when reviewing:

  • It is still possible to select multiple terms in the term search dialog but a warning will appear if you select more than one term.
  • The focus is not directly set on the search button. So pressing "Enter" will press OK which does not do anything when nothing is selected
  • it is not possible to select vocabularies with the term search

Created a ticket for remaining issues -> #8763

#15 Updated by Patrick Plitzner 7 months ago

  • Target version changed from 287 to Release 5.12

#16 Updated by Patrick Plitzner 7 months ago

  • Related to bug #8763: Remaining issues for "Move term" in term editor added

#17 Updated by Andreas Müller 7 months ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 90 to 40
  • For this usecase the title and the description in the term selection wizard needs to be adapted. It should be something like "Choose parent term".

  • Also the vocabularies should be choosable from to move a term to another vocabulary as top level term (maybe we can take the state if exactly 1 vocabulary is selected but no term is selected).

  • The term itself should not show up in the list

  • Multi-select should not be possbile immediately when selecting the terms (currently a warning comes after "Finish" that this is not possible)

#18 Updated by Katja Luther 6 months ago

  • Target version changed from Release 5.12 to Release 5.13

#19 Updated by Katja Luther 5 months ago

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

this is fixed now, please review

#20 Updated by Katja Luther 5 months ago

  • % Done changed from 40 to 50

#21 Updated by Andreas Müller 4 months ago

  • Related to deleted (bug #8763: Remaining issues for "Move term" in term editor)

#22 Updated by Andreas Müller 4 months ago

  • Duplicated by bug #8763: Remaining issues for "Move term" in term editor added

#23 Updated by Andreas Müller 4 months ago

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

Vocabulary search is an exact search now while term search is a "contains"-search. The later is what is more expected for the general term search. Also *-Search does not work vor vocabularies.

#24 Updated by Andreas Müller 4 months ago

Pressing cancel results in a warning "you have to select one single term". Cancel should not generate warning as nothing is expected to happen.

#25 Updated by Andreas Müller 4 months ago

When moving a term to another parent which is part of another vocabulary the term disappears in the UI. Only closing and opening term editor makes it appearing again.

#26 Updated by Andreas Müller 4 months ago

Andreas Müller wrote:

When moving a term to another parent which is part of another vocabulary the term disappears in the UI. Only closing and opening term editor makes it appearing again.

This is not the case when moving it to another voc as root.

#27 Updated by Andreas Müller 4 months ago

Terms and vocabularies are not clearly distinguished now in the search dialog. Especially because vocabularies are shwon 2x now on the left (for filtering) and on the right (for selecting).

Maybe we should add some note in brackets saying that this is a vocabulary or we use a different color for vocabularies as we do in the term editor tree.

#28 Updated by Andreas Müller 4 months ago

Please decide what can/should be fixed now and what better will be fixed after refactoring the term editors.

#29 Updated by Katja Luther 4 months ago

  • Related to feature request #8885: Distinguish between terms and vocabularies in term search dialog added

#30 Updated by Katja Luther 4 months ago

Andreas Müller wrote:

Terms and vocabularies are not clearly distinguished now in the search dialog. Especially because vocabularies are shwon 2x now on the left (for filtering) and on the right (for selecting).

Maybe we should add some note in brackets saying that this is a vocabulary or we use a different color for vocabularies as we do in the term editor tree.

move this to a new ticket -> #8885

the other issues are solved.

#31 Updated by Katja Luther 4 months ago

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

#32 Updated by Andreas Kohlbecker 4 months ago

I discovered a dangerous behavior of the "Choose Parent" dialog:

When the focus is set to the filter text field one would expect that hitting ENTER would trigger the search to be executed.
But instead the Enter-Key seems to be bound only to the "Finish" button so that the move operation can be triggered unintentionally.

(BTW, a button should be highlighted if it is the active button, that is when the pressing the ENTER key will trigger its action.)

I suggest to change the dialog behavior so that only the search is triggered when hitting enter.
The action of the finish button should never be executed this way.

#33 Updated by Katja Luther 4 months ago

  • Status changed from Resolved to Feedback

#34 Updated by Katja Luther 4 months ago

In windows the finish button is highlighted after selecting the parent and when no parent is selected disabled.

I think this is the normal behaviour? But why this is not the case in linux, I have to do some research.

#35 Updated by Andreas Kohlbecker 4 months ago

Katja Luther wrote:

In windows the finish button is highlighted after selecting the parent and when no parent is selected disabled.

I think this is the normal behaviour? But why this is not the case in linux, I have to do some research.

I the Finish button also marked active when the focus is set on the text field?
This actually is the more severe problem.

#36 Updated by Katja Luther 4 months ago

  • Status changed from Feedback to Resolved

#37 Updated by Katja Luther 4 months ago

  • Assignee changed from Katja Luther to Andreas Kohlbecker

#38 Updated by Andreas Kohlbecker 4 months ago

  • Status changed from Resolved to Closed
  • Assignee changed from Andreas Kohlbecker to Katja Luther
  • % Done changed from 50 to 100

Excellently solved!

I could not find further problems or glitches which are not yet handled in other tickets.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)