Can't follow links with ID in org-mode

[degiz]

Describe the bug
Seems to be very similar to #696
Logseq won't follow the links with ID which are generated by org-roam v2 in Emacs.

To Reproduce
first.org

:PROPERTIES:
:ID: 0d0c1093-7bc3-48a7-999b-534e20e92954
:END:
#+title: Mixing
* Topics
- Roland [[id:01fb71c0-798f-4485-9a8f-c6259c126469][808]]

second.org

:PROPERTIES:
:ID:       01fb71c0-798f-4485-9a8f-c6259c126469
:END:
#+title: 808

Expected behavior
From the first.org I'd expect to click on 808 and go to the corresponding file.

Screenshots
Attached is the screenshot - seems like Logseq sees the 808 as a link, but won't follow on click.

Desktop (please complete the following information):

• OS: MacOs 11.6
• Version 0.5.1

[GTrunSec]

I got same issue on Linux(NixOS appimage)

[stefanv]

Confirmed online with v0.5.2.

The linked document is not included in the page graph, and the link it provides to the browser to follow is id://<uuid>.

[romariorobby]

Any updates on this?

[codygman]

I just downloaded logseq to use with org-roam as an android client (or if in the mood for a gui application) this weekend and it looks like this is still an issue and links inserted from roam cannot be followed.

If you set :org-mode/insert-file-link? t in config.edn then you'll get links created in logseq that org-roam can follow, but not links that org-roam sees as backlinks.

I suppose for now using both org-roam v2 that uses uuids rather than file links and logseq together isn't an option.

Or maybe all of my issues are just due to #2286?

Related:

• Integrate with LogSeq org-roam/org-roam#1619
• https://coredumped.dev/2021/05/26/taking-org-roam-everywhere-with-logseq/ (this has the issue that you can't write things in org-roam anymore basically)
• https://discuss.logseq.com/t/logseq-org-mode-compatability/869/4

[codygman]

It seems the current resolution is WONTFIX:

We don't plan to change this in the near future because it'll need a lot of changes in the current code. We'll revisit this later. Closing this now as all feature requests are managed in https://discuss.logseq.com/ now.
This will be tracked on our roadmap.
https://trello.com/c/zdRWuPZI/614-feat-allow-links-to-ids-that-are-not-uuid (link dead now)

• Allow links to ID's that are not UUID #698 (comment)

[stefanv]

@codygman My reading is that the WONTFIX applies only to using non-UUID IDs, and that UUID links are supposed to work.

[TheLostLambda]

I've made a kinda ad hoc converter (a one-way change from org-roam v2 to Logseq) if others are interested!
https://github.com/TheLostLambda/org2seq

If you are actually interested in using it, feel free to get in touch and I can adapt the program to fit your needs / be a bit more general purpose!

Definitely doesn't work for block links though ;-;

[m-dwyer]

It definitely seems like it should work. If I create a new node in org-roam v2 called foo, then link to a node called baz, then in logseq I cannot navigate from foo to the baz link. But, if I open baz, it shows foo as a linked reference:

Not really very familiar with clojure, but guessing one of the conditionals here fails, it falls through to the else, and generates an external link instead? (Can see it as a normal anchor tag and href using the inspector)

logseq/src/main/frontend/components/block.cljs

Line 954 in e65c81b

(and (= (get-in config [:block :block/format]) :org)

Basically for some reason, it seems to fail to identify org mode file, or the id:// protocol, and so it doesn't attempt to look up the associated block by UUID. Instead, it treats the link as an external link and creates an anchor tag as <a href="id://some-uuid-here">

[ribelo]

The problem lies elsewhere. org-roam v2 puts the file id into properties at the top, and logseq reads the id as not the file id, but properties id

[cartwmic]

logseq/src/main/frontend/components/block.cljs

Line 963 in b260648

(= (string/lower-case protocol) "id")

Changing the above line to

(= (string/lower-case (:protocol (second url))) "id")

allowed me to follow org roam v2 links in logseq desktop app. The graph still doesn't represent the org roam v2 links though. Still investigating why that might be. Seems like the datalog entries that represent these org roam v2 links aren't correct from what I've ascertained thus far. But I'm a complete clojure (and datalog) noob so take that with a grain of salt.

[llcc]

Hi guys. Thanks for the reporting. This will be fixed in the next release.

[cartwmic]

@llcc

After checking out your branch, the inability to follow org roam v2 links is indeed fixed. The branch doesn't seem to resolve the links not showing up in the graph, though. I dug through it a bit and managed to fix the graph links not showing up: master...cartwmic:fix/org-roam-v2-link-regression

My solution seems a bit hacky though. It seems like the issue with the links not showing up has to do with there not being a :block/name attribute for org roam v2 page/block references. So I grabbed the name for those references from the :block/properties attribute instead and updated the node name mapping for the graph accordingly. I haven't been able to figure out the best place to fix the org roam block ref entities not having a :block/name attribute (if that is a more desireable fix then what I have above).