EDIT

Please also check if type information is still available (I did not check)

At the first view it seems that the dto is not filled correctly.

The derivates column should contain icons for scans, DNA data or character data

see code :

            array(

              'data' => ($sob_dto->hasDna ? $sequence_icon : "") . " "

                . ($sob_dto->hasDetailImage ? $detail_image_icon : "") . " "

                . ($sob_dto->hasCharacterData ? $character_data_icon : ""),

              'class' => array('summary_row_cell', 'summary_row_icon')

            )

if this is not the case, nothing is shown

This seems to be a problem of the derivedUnit or field unit DTO, because the flags hasDNA, hasImage etc are not filled correctly.

Katja Luther wrote in #note-6:

The compressed table also shows wrong data:
B 40 0042054 is shown as derivate with determination Gomphonema truncatum Ehrenb.

This is true. However, it is more or less a known issue and maybe even wanted. The compressed table is not made for complex multi-taxon sample derivation trees. Therefore it can not handle specimen types like material samples well. In such a case it seems to show only the preserved specimen children of a field unit and does not check if they really belong to the taxon as it expects a single taxon field unit. This behavior may be further discussed but it works well for typical higher plant derivation trees, not for algae. For algae the tree representation should be chosen as it is the case in the algae portal.

We may create a new ticket for this issue. This ticket here should only be about the regressions mentioned.

By the way, more astonishing I find that for on https://portal.cybertaxonomy.org/algaterra-new/cdm_dataportal/taxon/cd5df62c-54dd-46e5-abee-20d119bbb6c5/specimens

Andreas Müller wrote in #note-7:

Katja Luther wrote in #note-6:

The compressed table also shows wrong data:
B 40 0042054 is shown as derivate with determination Gomphonema truncatum Ehrenb.

This is true. However, it is more or less a known issue and maybe even wanted. The compressed table is not made for complex multi-taxon sample derivation trees. Therefore it can not handle specimen types like material samples well. In such a case it seems to show only the preserved specimen children of a field unit and does not check if they really belong to the taxon as it expects a single taxon field unit. This behavior may be further discussed but it works well for typical higher plant derivation trees, not for algae. For algae the tree representation should be chosen as it is the case in the algae portal.

We may create a new ticket for this issue. This ticket here should only be about the regressions mentioned.

But I agree that this could be handled better even with the limited possibilites of the compressed table.

Generally it works as expected and ticket can be closed if alignment ist fixed.
I added a further derivate to field unit "Germany, Berlin, alt. 165 m, 52°31'1.2"N, 13°21'E (WGS84), 28 Mar 2016, Ehrenberg D047" to check if a specimen that is in the same tree but is not explicitly linked itself or by a parent unit does not show up in the table as it is not expected to show up.
This data change may create test problems in other tests. If so we need to decide how to handle this (delete data again or adapt tests). I started dataportal build.

The tests did all successfully run in dataportal.
Is there already a test that fails if collection "CBFS" or label "Not linked to taxon" appears somewhere on the page? So explicitly testing that unlinked specimen are not shown.
It is ofcourse not really part of this ticket but could be helpful to avoid something like this during future refactoring.

Andreas Müller wrote in #note-12:

The tests did all successfully run in dataportal.
Is there already a test that fails if collection "CBFS" or label "Not linked to taxon" appears somewhere on the page? So explicitly testing that unlinked specimen are not shown.
It is ofcourse not really part of this ticket but could be helpful to avoid something like this during future refactoring.

I did not find any tests, but maybe it is easier to write the tests on cdmlib side, and check whether the web service returns the correct specimens.

Katja Luther wrote in #note-14:

...
I did not find any tests, but maybe it is easier to write the tests on cdmlib side, and check whether the web service returns the correct specimens.

It might be easier but it is not a fully correct integration test. What if we use another method in future then the check in the service layer is of no help.