Thank you. It looks like john.edw_gmail.com beat you to this by a few hours. I will investigate tonight whether I’d rather try this or keep to the original solution, with Saq’s and pmario’s fixes. But this is certainly worth considering. I also like the idea of moving the deserialization into a single place instead of running part of it on the external site and the rest in the code discussed above.
Thank you for the help!
Coming to this late. But I’m running two variants of this kind of solution, and want to add to the discussion in case it’s helpful:
One variant is kookma’s refnotes solution, which takes pasted bibtex json data, using a custom dropzone (or “paste zone” in practice for me), which you can find here: Refnotes 1.9.0 — references, citations, footnotes and abbreviations in Tiddlywiki … and transforms in various ways to translate into the TiddlyWiki field-structure that refnotes uses (prefixing most fields with bibtex- etc.).
The other takes jsons exported by my university’s (= your alma mater’s 
) moodle LMS, and makes various transformations on these (since the json I can export from moodle doesn’t even come with a title field, for example), so they can be imported. See discussion thread with key post here:
It absolutely is helpful. These seem similar to two other recent suggestions. The three of them, taken together, seem to make me want to reconsider my approach, and try a drop-zone with all the conversion happening inside TW instead of in the console of that intranet site. I’ll have to think about it more, though, as I believe the dropzone approaches might require more user steps than my current one. That’s not all bad, though, as some of those steps might help them get more familiar with TW. So, more to ponder!
Thank you very much for your insight and your examples!
Actually that is what I implied by “use later”, and in fact the clipboard already acts like that.
this way you can always improve the process.I don’t know; I’ve heard a lot about it, but never used it, or even investigated its capabilities.
I’ve been using bookmarklets since they were called favelets. I do understand how they work. I have dozens on both personal and work browsers. I’ve never written to the clipboard from them, but can see how that would be useful. But the console is also useful, and a lot more flexible. I will consider this, but am not happy with the idea of telling users, “Drag this link to your bookmarks bar (after unhiding it if it’s hidden). Then, to import a member go to the Inside intranet page, click that bookmarklet, enter the member’s name at the prompt, then when it’s visible, hit another button to copy the result to the clipboard.”
I’m not sure that last is necessary. I expect it would be, given Firefox’s security model around the clipboard, but my users will likely be using Chrome. The point is that entering the name and clicking the button would trigger an AJAX request, and the data would be available only in the asynchronous callback, which likely would not be what FF considers inside a “short running user-generated event handler”, so another user action would be necessary. But this is from memories a decade old; this may have changed.
It would have to run from the intranet page to be useful, so yes, the user would have to install them in my case.
I mentioned in the OP and in at least two previous responses to you that I cannot, not without a hugely painful integration with company single-sign-on authentication. Even if TW could support that, it’s quite unlikely that the company would grant permission for it.
Well, the examples were Variables in Memory, LocalStorage, SessionStorage, IndexedDB, Cookies, the Cache API, and In-Memory Databases. I’m pretty sure none of those works cross-domain. If they did, it would be quite frightening.
I’m wary of bookmarklets for my users. There’s no way I would look to a browser extension!
I could see this being very useful!
Well, I’m talking about where the logic is run, not where it’s maintained. Right now the logic to call the service and transform the result into TW format is maintained in the tiddler $:/_/my/data/js-code/inside-info, but this is combined with the name we’re adding and copied to the clipboard, to run in the console of the intranet page. I could instead use a <$dropzone> as others have been suggesting, and a custom deserializer that does that work on input.
So I’m building and maintaining the logic in the only place I have any influence. But I am running it elsewhere. I have been looking at these techniques, and, while not completely decided, am leaning to keeping the original approach.
Its good you have an acceptable answer and i will leave it there. Only you know about your source server. I do think some of your assumptions or understanding of my suggestions are not altogether accurate, nor do I expect you to run with my hunches, only some of which I have tested.
Best of luck
Thank you again for all your insights!