[feature request] Auto-exporting saved searches

edited February 22, 2018
Hello

We are a few to ask the author the Better Bibtex plugin to add a feature to auto-export saved search references.
He responds it's not presently possible due to a Zotero limitation (a small one, see below).
Is there a way to change that ?

For further informations, see :
* the issue on github repository : https://github.com/retorquere/zotero-better-bibtex/issues/904
* the request done on the Zotero-dev list : https://groups.google.com/forum/#!topic/zotero-dev/QZcJqgmORUA

Thanks a lot.
  • I'm actively involved in the development of course, but I did encourage users to make their interest known; as it involves a change in Zotero, I thought it'd be good to have clear it's not just me looking to expand BBT on theoretical grounds.
  • edited February 22, 2018
    This post of Emiliano make me realize that I've not explained what's my interest in such a feature. Here are few explanations.
    My library is organised exclusively with thematic collections, rather than with thematic tags (which are limited in number, because of the only nine colors). I prefer to use tags to adding informations for myself, for which colors add a real value. For instance: #toread (in blue), #tobuy (in red), #tosummarize (in yellow), and also to gather references for a specific use like [PhDbibliography] (in green).
    That's why, in order to write a chapter of my PhD thesis with LaTeX, I need to export in Bibtex my references tagged in green, but not all, only the ones stored in some specific collections. In doing so, I use a saved-search. Everything works well manually. But it would be much better if the export was fully automatic, like BetterBibtex offers for collections.
  • Which I could do, if I could see that the export being performed by the user was initiated from a search "collection".
  • edited February 22, 2018
    This is of interest to me as well. I use tags and smart searches to create local groups, so being able to export these groups automatically via BBT is very useful.

    EDIT: clarified that it's the auto-export I'm talking about.
  • (for the benefit of other who may stumble in here, export of these groups works fine in Zotero, it's just BBT auto-export that's currently missing)
  • I use colored tags and number keyboard shortcuts to add items to saved search collections. Saved searches are nicely kept updated with zotero 4 and BBT. It's the quickest, best workflow I've found so far. I reverted back to Zotero 4 when I saw 5 didn't allow for auto-exporting saved searches.
  • I find being able to have BBT auto-export saved searches very useful, too. This worked nicely with Zotero 4/BBT, and it’s a pity it’s broken with Zotero 5.
  • edited March 7, 2018
    I have to add that Zotero didn't break anything in the move from 4 to 5, it's just that detecting that a search was being exported used *very* invasive monkey-patching of Z4. I want to really scale back the complexity of monkey patching BBT does, certainly now that the async architecture Z5 raises the risk of hard-to-debug race conditions.

    (edit: rave conditions are notoriously hard to set down, but I meant race conditions of course)
  • People who use zotero and BBT together will all vote for this I guess. Search set is a far more smart collector than the category.
  • edited May 18, 2021
    Technically, I monkey-patch Zotero.Translate.Export.prototype.translate to inspect what is being exported, and put it in my auto-export administration if I can find something that I can use to reproduce the export.

    For a library export, I can remember ._export.type (which will be 'library') and ._export.id, (the library ID); if a reference changes, I can check whether that library was affected.

    For collections, I can remember ._export.type (which will be 'collection') and ._export.collection.id, (the collection ID); if a reference changes, I can check whether that collection was affected.

    For searches being exported, only the list of items that are in that search *at that time* are available. To test even *whether* a search is being exported, I'd have to run all searches you have.
    The way I used previously was to monkey-patch the right-click-to-export on the search (at which stage I have the search ID), replace data into the export request being set up with non-compatible data, assume that that data will travel all the way to the Zotero.Translate.Export.prototype.translate call unscathed without messing up anything in the interim in Zotero, and then undoing that just before calling the original. Or something to that effect at least, it's been a while, but the code wasn't pretty. I don't mind monkey-patching but I like it to be localized so it's less likely to cause interference, and this string of monkey-patches that modified the internal structures that Zotero expected assuming I could undo those changes just in time... what with async ruling the land now... no.

    To do this cleanly, all I'd required is ._export.type be set to something like 'search' and the search ID to be present (e.g. on ._export.id or on ._export.search.id), or even just the presence of ._export.search (with an ID), and I'd be golden. I assume Zotero is not currently doing this because it's not necessary for regular Zotero usage; searches are (relatively) expensive, and if you right-click the search to export it, it is first displayed, so the search has just been executed, and the results can just be used for the export, so Zotero hands that list to the exporter. There's no need to pass the search to the exporter as you would never have to re-do the search in Zotero in that path.

    Note that even if a ._export.search were added, auto-exports for search is still relatively expensive. When a reference changes, I have to run the auto-exported searches to see if the changed reference is in the result set, so you wouldn't want to have a lot of these with complex conditions set up for auto-export.
  • Any updates on this matter?
  • As far as I know, nothing has changed.
Sign In or Register to comment.