source URL on library record is declared read/write in the sdef but writes are silently ignored on .eml records
Log from Script Debugger get selected records of browser window 1 of library document 1 get source URL of library record id 1341 of library document “Test import.eflibrary” (Current source URL: message://%3Cwvud50pnpeughk2nv32s7hndle8w2a8h44w%``40convertkit-mail4.com``%3E) set source URL of library record id 1341 of library document “Test import.eflibrary” to “maven-message://test123” get source URL of library record id 1341 of library document “Test import.eflibrary” (New source URL: message://%3Cwvud50pnpeughk2nv32s7hndle8w2a8h44w%``40convertkit-mail4.com``%3E)
The source URL is settable for file records. Your script probably is writing maven-message://test123 into the database. Currently, however, there’s an override where .eml files always display the message: source URL that’s generated from the underlying message data. I’ll look into whether it’s possible to make the URL from AppleScript override that if present.
Thank you for the lightening fast clarification — that’s very helpful.
The goal from my side was to make the maven-message:// URL clickable in EagleFiler’s Info inspector, so that clicking it opens the originating message in MailMaven with its full tag data intact — rather than opening the stored .eml file which has no tagging metadata.
In the meantime I’ve worked around this with a FastScripts script that reconstructs the maven-message:// URL from the .eml filename and calls open location — so the round-trip navigation is working today.
I appreciate you looking into whether a script-written URL can override the display behaviour. I should mention that Scott Morrison at SmallCubed is planning to contact you about native EagleFiler integration for MailMaven — once that’s in place, EagleFiler may handle the source URL at import time from an X-MailMaven header, which would make this a non-issue. So please don’t feel this needs to be a priority fix if the native integration path is cleaner.