EDIT

The status actually seems to be missing in the data http://api.cybertaxonomy.org/flora_cuba/portal/name/6b7cef15-1e9c-45ca-bc44-207b166231c2/status.json

last bug fix : 72e0e4a r27721

The status is still missing in the portal, though it exists in the data: http://api.cybertaxonomy.org/flora_cuba/portal/name/69ef933d-70ff-48b9-a86e-3d9391669838/status.json

http://api.cybertaxonomy.org/flora_cuba/portal/name/7e50e9c4-1626-483e-b163-b52e691e7abd/status.json

But the status type is missing in the web services as it looks like. Maybe this is the reason.

now that the dataportal installation problems on edit-production are solved the "non xxx" are no longer missing:

http://portal.cybertaxonomy.org/flora-cuba/cdm_dataportal/taxon/3368d326-afe7-414f-841a-4f182010fd1e

The "non" relationships are shown only in one direction ( later homonyms, treated as later homonyms and is blocking name ), this is currently hardcoded. Please open a new ticket if this should be completely flexible and configurable.

Generally this ticket is fixed, but there are a few related open issues:

• the related name (name behind "non" does not yet show a status if a status exists). This is probably because it only shows the title cache, not the full title cache. The status is part of the full title cache. Maybe we also need discussion with users, if the status is wanted, before we spend time for implementation

• the current implementation is only for "non" names. At the same time many of the available name relationship types will never be displayed by "non". E.g. alternative names, orthographic variants, basionyms, replaced synonyms, validated by, later validated by, etc.. If this section is meant ONLY for "non" names we should remove these from the list as they are misleading.

• the data portal admin section should give some short explanation that it handles the "non" name relationships, not name relationships in general. E.g "Name relationships shown as "Aus bus (non Aus cus)" or some better name parts.

• if we keep the hard coded version with only one direction we should rename "is blocking name for" to "is blocked by". This is consistent with the other relationships where the right part ("to part") of the relationship is shown behind the "non" while the left part ("from part") is shown in front

• as mentioned above we could allow selecting directions, but maybe we should wait with it until there is an explicit requirement for this

• generally we may want to implement additional name relationships. E.g. "has original spelling" is usually displayed like "Aus bus 'buus'". Maybe we need a cache strategy for this. Ask users if there are other rules like this for other relationships.

Please feel free to decide which of the above issues should go into a separate ticket and what can be done on the fly within this ticket.

all the above issues are now in separate tickets: #5857 #5856 #5855