Decide which child file to open by default
Hi!
I have a few files for which I have two pdf attached (eg the paper and its supplementary information).
Is there a way to change the one opened by default by Zotero when I double-click on the reference?
I tried to rename the child files but it did not change anything.
Thanks in advance for your help!
I have a few files for which I have two pdf attached (eg the paper and its supplementary information).
Is there a way to change the one opened by default by Zotero when I double-click on the reference?
I tried to rename the child files but it did not change anything.
Thanks in advance for your help!
Upgrade Storage
Suggested:
R-click on document > Manage Attachments > Set as default
This does not seem to be correct. I detached all child items except the "desired default pdf" (DDPDF) from their parent (which correctly caused the DDPDF to be opened upon double click), and then re-attached the other child items. This restored the previous, unwanted, opening behaviour.
It appears that rather than the order in which they were attached to the parent, it seems that the order in which they were added to the zotero library is what matters. I believe this to be the case because in a second attempt, I removed the non-DDPDF child items, and then didn't reattach them, but rather attached copies of their files (which I easily obtained by selecting "show file" from the context menu) (to save space, I then deleted the old, now duplicate, child items. This resulted in the desired behaviour, but is cumbersome.
It will be possible to set a different primary attachment in a future version.
By future version you mean Zotero 7 ?
looking forward to it!
> It will be possible to set a different primary attachment in a future version.
Is it planned to appear in some minor release of the 7.x series?
Best regards
Not a dealbreaker, this is still an awesome workflow, but it seems like an easy fix for a big quality-of-life improvement.
I think @dsholmes suggestion above would work.
But I'll add another suggestion: a way to quickly see if there's more than one PDF under an entry. As it stands, looking at each entry I don't know if there's only one, or more, PDFs under it.
This could be shown in the attachments column, for example, by have two overlaping PDF items instead of one (to denote a group). Though there may be better ways to do it. Maybe a number showing how many (PDF) attachments there are for each entry.
I now have a strange situation, where for an item in my library, my iPad insists on opening a supplementary file by default, whereas on Mac the default item is the main text (as it should). I have tried removing the supplementary PDF, and re-adding it again, but without success. My iPad keeps insisting on opening the supplementary PDF file (whenever it is available) for this item by default.
I also agree that it would be very useful to filter/distinguish items with multiple attachments. However, the automatic snapshot will certainly count as one and this means most will have more than 1 attachment. Perhaps it could be another optional column in the list.
Any updates on when this will be available?
I had the same problem, and implemented a solution as a plugin using AI.
Currently, there is only one function: right-clicking a PDF and setting it as the default file to open.
I have only tested it on my macOS system. Any suggestions are appreciated.
https://github.com/PikaPei/zotero-default-attachment
zotero-default-attachmentplugin.) I took a quick look at the code. What it appears to do is store default-attachment overrides in a hash/dictionary that is stored under a single key¹ in the user's preferences. The ZoterogetBestAttachmentfunction/method (that is used to choose the file to open by default) is patched to first check that hash for a match and if found to return the associated file's ID.¹
extensions.zotero.defaultattachment.mappingsDiscussion
This code is partly or fully «AI» generated and lacks a Theory of Operation so it'd take a full audit of it to determine exactly what it's doing. That said, the intent and operation of most of the code appears clear. On closer examination the code seems fine with no obvious defects.The mappings are stored out of band, not in the item though so that could have repercussions for backup/restore, copying, sharing, etc.; I would have preferred seeing the default-attachment overrides be stored within each affected item's data structure.
The plug-in only allows PDF files to be set as default. To change this one could probably just modify
menu.tsto remove that restriction (search for mentions ofapplication/pdf). Doing so might not be sufficient to allow any file type to be set as default but based on how the code performs overrides that should do the trick.[Apologies if any of that came across in a hostile tone.]
It is still AI generated, but hopefully addresses your concerns, until this is fixed upstream by Zotero.
The default choice is stored on the item itself — as a tag on the chosen child — so it syncs across computers, survives backup/restore, and follows the item, rather than living in a local preference. The marker is an emoji tag (▶️ wv-defatt), so where it appears it's easily visible and self-explanatory at a glance — and it's registered as an automatic tag, so it can be hidden in the Tag Selector via the "Show Automatic" setting and never clutters your own tags. The slug is deliberately not an English word so it can't surface in quick-search results for real terms.
It's also not limited to PDFs: any openable child can be the default, including linked URLs and child notes. And it coexists with Pei Huang's plugin — their pick is honoured as a fallback, there's an optional one-time import of its mappings, and Weavero never modifies that plugin's data.
Regarding «AI» usage, I hope that prior to public release you're thoroughly vetting the code and fully understand its behaviour, including edge cases and the like. (Speaking out of [IMO] well-founded caution.)
But it is not possible to anticipate all use cases.
So bug reports from the users in the Weavero GitHub issues are very useful for the consolidation of the plugin.
If you find any problem or have suggestions to improve, your feedback will be useful.