In study-study conflict, links go to synth rather than alternative study

[snacktavish]

E.g. in https://devtree.opentreeoflife.org/curator/study/view/ot_1022/?tab=home&tree=tree1&conflict=pg_2866@tree6656

The node links go to https://devtree.opentreeoflife.org/opentree/argus/@node1160951

Rather than https://devtree.opentreeoflife.org/curator/study/view/pg_2866?tab=home&tree=tree6656&node=node1160951

[bredelings]

Yeah, the conflict info is talking about node1160951 in tree2, not node1160951 in synth. Previously when tree2 was always synth or ott, nodeXXX always referred to the synth tree. But now it can refer to a study tree.

In this case, the correct URL is:

https://devtree.opentreeoflife.org/curator/study/view/pg_2866?tab=home&tree=tree6656&node=node1160951

but what we get is:

https://devtree.opentreeoflife.org/opentree/argus/opentree13.4@node1160951

The conflict JSON (for a different node) would look like:

    "node60": {
        "status": "supported_by",
        "witness": "node1161124"
    }

The witness here is in tree2, which is a study tree.

[jimallman]

OK, I have a partial fix in progress on devtree. It correctly detects a study-tree node in conflict, and builds a nice direct URL that highlights that node in the curation app. This seems to work correctly with all internal nodes in the conflict-tree view, since these appear to retain their original node IDs (as unlikely as that seems to me). But as for the tips...

Yeah, the conflict info is talking about node1160951 in tree2, not node1160951 in synth. Previously when tree2 was always synth or ott, nodeXXX always referred to the synth tree. But now it can refer to a study tree.

There's the rub. The conflict information doesn't seem to include the original node id used in the reference (study) tree. Instead, it's picked up a new ID (often something like ott785961, based on its mapping I guess). For example, in the above URL, here's the conflict information that points to Somateria mollissima in the API response to /v3/conflict/conflict-status:

 "node50": {
  "status": "terminal",
  "witness": "ott785961",
  "witness_name": "Somateria mollissima"
 },

Notably absent is its original node ID node11161116 in the source tree. So we can build a URL to show this study and tree in the curation app, but it will fail to find the matching node by ID, so no node is highlighted.

Possible fixes include

• adding this original node ID to the API response, if available, or
• trying to highlight a node by its label (i.e. Somateria mollissima) rather than node ID. I'm guessing this would be more prone to errors, since there might be multiple nodes with the same label. @bredelings @snacktavish Thoughts?

[bredelings]

Yeah, I noticed this too. Its possible that pointing to the taxonomy for leaf nodes is the behavior we want. Maybe we can talk about this over zoom.

[jimallman]

Fixed in https://github.com/OpenTreeOfLife/otcetera/commit/b184d6d7379f0f7657b3b007e1939cb849c893e5

Working now on devtree. Marking this as closed!