EDIT

But it works when adding an explicit sensu reference. But explicit sensu is not a requirement.

Andreas Müller wrote:

Strange, with this entry:

the webservice even does not return a second entry though it exists. Need to check why.

ohh, sorry, it was on unpublish (so unpublish works !! ;-)

Deduplication must NOT take place if the rel. sec. differs (e.g. only one of the MANs has a rel. sec.). This is not yet correctly implemented.
Also everything else needs to be equal except for MAN.sec and MAN.secDetail. E.g. if the doubtful flag differs either for the MAN taxon or for relation also no deduplication should take place (as it is no duplicate).
Also the relationship type needs to be equal (once pro parte and partial works).

Andreas Müller wrote:

& handling does not yet work correctly in teams. Probably a formatter issue #7666.

This was a formatter problem (#7666) which was fixed by cdmlib|c331fa7e

I tested the above behavior. The reason is that secDetail differs (or misses in one case). secDetail is part of the secSource and may be different.

The MANs are still unsorted. In the above example you can see that Achillea santolina sensu Chrtek ... is before Achillea santolina sensu Baumel but shouldn't.

As far as I know Katja implemented a Comparator for same issue in TaxEditor. If possible we should try to reuse it. But may be this is not possible because of the deduplications that do not exist in TaxEditor.

Andreas Müller wrote:

Exception for second MAN of Achillea santolinoides Lag.

for this data on test.cyprus

This is not yet fixed. The exception still exists. #7658#note-17

Deduplication should include appendedPhrase part I think (this is also not yet implemented in the server side misapplication deduplication and also has not yet been discussed in our last discussion on deduplication).

E.g. - "Achillea santolina" auctrs. afr.; Meikle 1988 should be deduplicated and not 2 entries.

This is because the appendedPhrase for MANs is usually used as kind of freetext for the sensu reference like in the above example.

Andreas Müller wrote:

Does not yet work for pro parte and partial MANs.

This is also still an open issue.

Fehler wie bei Achillea santolinoides beseitigt, aber die Fußnoten bei den nicht MANs fehlen noch - kommt in 3.4!

Andreas Kohlbecker wrote:

Fehler wie bei Achillea santolinoides beseitigt, aber die Fußnoten bei den nicht MANs fehlen noch - kommt in 3.4!

jetzt müsste es perfekt sein!

der Review lohnt sich nun.

"auct." (appended phrase) does not show up, e.g.

• "Achillea santolina" , non Test , but should be "Achillea santolina" auct., non Test

The auct. is in the webservice but seems to get lost in the portal code

Andreas Müller wrote:

"auct." (appended phrase) does not show up, e.g.

• "Achillea santolina" , non Test , but should be "Achillea santolina" auct., non Test

The auct. is in the webservice but seems to get lost in the portal code

This is only the case, if no sensu reference is defined

Deduplication takes not yet place when the relationship is of type "pro parte Misaplied Name" or "partial Misapplied Name", but should. But of course only if both types are equal, so don't mix MAN with ppMAN or partialMAN with ppMAN ...

Andreas Müller wrote:

Deduplication takes not yet place when the relationship is of type "pro parte Misaplied Name" or "partial Misapplied Name", but should. But of course only if both types are equal, so don't mix MAN with ppMAN or partialMAN with ppMAN ...

Oops, this is a new requirement.

Andreas Müller wrote:

Andreas Müller wrote:

"auct." (appended phrase) does not show up, e.g.

• "Achillea santolina" , non Test , but should be "Achillea santolina" auct., non Test

The auct. is in the webservice but seems to get lost in the portal code

This is only the case, if no sensu reference is defined

It is actually the "Combination Authors" data which causes the problem.

The sort order is still not correct. We should first have pro parte/partial synonyms, then invalid designations, then MANs followed (or including?) pro parte/partial MAN and finally concept relationships.

Currently they come mixed up:

This problem is not release critical. We can fix it in 5.4. Maybe only moving up ppSyn to top would be nice but if not it is acceptable.

Andreas Kohlbecker wrote:

all mentioned bugs fixed!

Tested the 2 issues. Both work.

So the only open issue is the sorting #7658#note-46

We may move this to 5.4 if not easy to fix.

And ofcourse the footnotes for non-MAN data are still missing. #7658#note-37 or should this be fixed already? If yes, it doesn't seem to work.