World Ferns 2146 of 2020-06-14, of 1140 of 2020-06-26: test report

[yroskov]

2020-06-22: @gdower Frontend version: c99dba2 June 17, 2020 9:47 AMBackend version: 507800e June 17, 2020 8:53 AM

• [x] Missing subfamilies in the classification (SF): There are 32 subfamilies in the source file: Lycopodioideae W. H. Wagner & Beitel ex B. Øllg. Huperzioideae W. H. Wagner & Beitel ex B. Øllg. Lycopodielloideae W. H. Wagner & Beitel ex B. Øllg. Mankyuoideae J. R. Grant & B. Dauphin ... and also: 45.9 | uncertain 48.1 | Pteridryoideae ined. 48.2 | Arthropteridoideae ined. 48.3 | Tectarioideae ined.

• [x] There is also rank T for tribe in the source file. However, there are only two records, and they refer to clades: Amauropeltoid clade Cyclosoroid clade Should be excluded from CoL. Both are not present in the classification, but names appear in the workbench.

• [x] Suborder Saccolomatineae is incorrectly placed as a genus (bug in the source file? there is no such status as SO): (I failed to find name Saccolomatineae in the source file). I can block the name in the Clearinghouse.

[mdoering]

Because we now have multiple identical Doryopteris in the assembly tree the sector targets do not match automatically:

     "id": 115587,
      "target": {
        "name": "Doryopteris",
        "authorship": "J.Sm.",
        "rank": "genus"
      },

     "id": 115586,
      "target": {
        "name": "Doryopteris",
        "authorship": "J.Sm.",
        "rank": "genus"
      },

Well, there actually is just one genus in the tree: http://api.catalogue.life/dataset/3/nameusage/search?rank=genus&q=Doryopteris

       "id": "4c365e96-ce54-41a7-81eb-be732733f51e",
        "sectorKey": 115576,
        "name": {
          "scientificName": "Doryopteris",
          "authorship": "J. Sm.",
          "rank": "genus",
          "code": "botanical",

Maybe the matching does not ignore whitespace as the authorships differ by a space? That should not be the case, but the new verbatim authorship change probably has introduced that. Hm no, tried and it doesnt make a difference. It actually seems the rematch button does only trigger a subject rematch, not a target one

[yroskov]

Rematch does not work:

[mdoering]

All 3 genera: Cheilanthes Doryopteris Grammitis are split in assembly tree again. DISGUSTING!

I can only see Cheilanthes being split, Doryopteris exists only once. And the reason Doryopteris is fine but Cheilanthes isn't is that Cheilanthes misses the blocking decisions! The main sector Polypodiales therefore copies all instances of genus Cheilanthes over to the assembly tree. :

[yroskov]

Geoff and me exercised with blocking Doryopteris in GSD today (that's why it's a sigle entry in assembly tree). However, blocking did not resolve a main problem: all species from "Doryopteris ." and "Doryopteris p.p." are missing in assembly.

Attempt to bring missing species in Doryopteris J.Sm. ended with a bug report:

[mdoering]

This is not a bug, its a bad request. You cannot create multiple sectors in a single project that share the same source taxon

[mdoering]

@thomasstjerne can we show a more user friendly message in case of 400 errors? Maybe just "Bad request" and show the error details on demand only? Created https://github.com/CatalogueOfLife/clearinghouse-ui/issues/666

[mdoering]

I just blocked the extra Doryopteris genera, deleted the old 2 genus sectors and recreated them with a union and then synced both. It all worked fine as expected and the result looks good to me: