EDIT

Katja Luther wrote:

... but the object already selected does not show up in the selection dialog. This is the same for all selection dialogs.

Is there a reason why it is such? Was it a requirement. Currently it looks strange to me but maybe there are use-cases from which it becomes more clear. Is it explicitly coded in the code?

Ordering and dot search seem to work well now.

Search on titleCache with * at the beginning (additionally to the nom.title) still does not work. Is this difficult to implement? To me it looks like nice feature so if difficult to implement we may want to create a new ticket for it. The current solution is not so intuitive because the user can see the titleCache in the result and will wonder why when restricting the search in a way that it does not match the nom.title there comes no result back.

Andreas Müller wrote:

Katja Luther wrote:

... but the object already selected does not show up in the selection dialog. This is the same for all selection dialogs.

Is there a reason why it is such? Was it a requirement. Currently it looks strange to me but maybe there are use-cases from which it becomes more clear. Is it explicitly coded in the code?

Yes, it is explicitely coded in the code. There is an attribute cdmBaseToBeFiltered in the base class of the selection dialog, which is filled with the actual object. I think the original idea was that if I want to change something, I don't need the object selected before.

Katja Luther wrote:

Andreas Müller wrote:

Katja Luther wrote:

... but the object already selected does not show up in the selection dialog. This is the same for all selection dialogs.

Is there a reason why it is such? Was it a requirement. Currently it looks strange to me but maybe there are use-cases from which it becomes more clear. Is it explicitly coded in the code?

Yes, it is explicitely coded in the code. There is an attribute cdmBaseToBeFiltered in the base class of the selection dialog, which is filled with the actual object. I think the original idea was that if I want to change something, I don't need the object selected before.

I had a look in the code and the idea of this attribute was another one. The idea was for example if the selection dialog is used for a taxonrelationship and it should not allowed to add the taxon itself, the selection dialog can filter the taxon out of the list. I will have a look in all selection dialogs and adapt it.

Andreas Müller wrote:

Search on titleCache with * at the beginning (additionally to the nom.title) still does not work. Is this difficult to implement? To me it looks like nice feature so if difficult to implement we may want to create a new ticket for it. The current solution is not so intuitive because the user can see the titleCache in the result and will wonder why when restricting the search in a way that it does not match the nom.title there comes no result back.

What Do you mean? That for an * at the beginning the search is only on the titleCache?
Thats not really clear because it also could mean that the search is on the nom title but the search patter should be at the end of the string.
If we want to have this feature we should use another wildcard for this.

Katja Luther wrote:

Katja Luther wrote:

Andreas Müller wrote:

Katja Luther wrote:

... but the object already selected does not show up in the selection dialog. This is the same for all selection dialogs.

Is there a reason why it is such? Was it a requirement. Currently it looks strange to me but maybe there are use-cases from which it becomes more clear. Is it explicitly coded in the code?

Yes, it is explicitely coded in the code. There is an attribute cdmBaseToBeFiltered in the base class of the selection dialog, which is filled with the actual object. I think the original idea was that if I want to change something, I don't need the object selected before.

I had a look in the code and the idea of this attribute was another one. The idea was for example if the selection dialog is used for a taxonrelationship and it should not allowed to add the taxon itself, the selection dialog can filter the taxon out of the list. I will have a look in all selection dialogs and adapt it.

Now I had another look in the history of the selectionDialogFactory and the usage of this cdmBaseToBeFiltered was the same as now from the beginning. Nils wrote this comment but never used the attribute like this. Always the current selection was filtered.

now searching with * at the beginning of the search pattern searches on abbrevTitleCache and titleCache

Andreas Müller wrote:

Deduplication of equals caches looks good now.

Search on titleCache does not yet work. E.g. create a Person with nomTitle "Aaaa." and titleCache "Bbbb".
Searching for Aaaa works but "*Bbbb" does not return a result.

sorry, it wasn't checked in yet...

Andreas Müller wrote:

With the above example Aaaa/Bbbb I get the following exception when exactly searching for "*B".
Entering "*Bb" works again and gives the correct result.

login : 
editor version : 4.3.0.201609191958
server :  / 
schema version : 
os : Windows Server 2012 6.2 amd64
java : 1.7.0_65
java.lang.NullPointerException
  at java.text.RuleBasedCollator.compare(RuleBasedCollator.java:351)
  at eu.etaxonomy.taxeditor.ui.dialog.selection.NomenclaturalAuthorSelectionDialog$2.compare(NomenclaturalAuthorSelectionDialog.java:218)
  at eu.etaxonomy.taxeditor.ui.dialog.selection.NomenclaturalAuthorSelectionDialog$2.compare(NomenclaturalAuthorSelectionDialog.java:1)
  at eu.etaxonomy.taxeditor.ui.dialog.selection.CdmFilteredItemsSelectionDialog$HistoryComparator.compare(CdmFilteredItemsSelectionDialog.java:3390)
  at java.util.TimSort.binarySort(TimSort.java:265)
  at java.util.TimSort.sort(TimSort.java:208)
  at java.util.TimSort.sort(TimSort.java:173)
  at java.util.Arrays.sort(Arrays.java:659)
  at java.util.Collections.sort(Collections.java:217)
  at eu.etaxonomy.taxeditor.ui.dialog.selection.CdmFilteredItemsSelectionDialog$ContentProvider.getSortedItems(CdmFilteredItemsSelectionDialog.java:2925)
  at eu.etaxonomy.taxeditor.ui.dialog.selection.CdmFilteredItemsSelectionDialog$ContentProvider.rememberResult(CdmFilteredItemsSelectionDialog.java:2938)
  at eu.etaxonomy.taxeditor.ui.dialog.selection.CdmFilteredItemsSelectionDialog$FilterJob.filterContent(CdmFilteredItemsSelectionDialog.java:2263)
  at eu.etaxonomy.taxeditor.ui.dialog.selection.CdmFilteredItemsSelectionDialog$FilterJob.internalRun(CdmFilteredItemsSelectionDialog.java:2199)
  at eu.etaxonomy.taxeditor.ui.dialog.selection.CdmFilteredItemsSelectionDialog$FilterJob.doRun(CdmFilteredItemsSelectionDialog.java:2170)
  at eu.etaxonomy.taxeditor.ui.dialog.selection.CdmFilteredItemsSelectionDialog$FilterJob.run(CdmFilteredItemsSelectionDialog.java:2157)
  at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

This was also a data problem, the person BGBM had no abbrevTitleCache and therefore we got a NPE. Now the comparator checks for null in abbrevTitleCache and titleCache. Normally this should not happen, because the abbrevTitleCache should not be null, but for older data we have to check.