Decide which child file to open by default

linaewen18

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!

bwiernik

Not at this time, sorry. PDF attachments will open in the order attached to the Zotero item.

dsholmes

This feature is needed! This problem also occurs when there are draft versions with comments that need to be kept.

Suggested:
R-click on document > Manage Attachments > Set as default

krueschan

@bwiernik wrote: "PDF attachments will open in the order attached to the Zotero item."

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.

dstillman

@krueschan: Yes, bwiernik just meant that it's the order that you save attachments to an item in your library, not that you can change this by moving attachments out of and back onto the item. It's just about the age of the attachment.

It will be possible to set a different primary attachment in a future version.

b0c5

> It will be possible to set a different primary attachment in a future version.

By future version you mean Zotero 7 ?

jeremyvancleve

> It will be possible to set a different primary attachment in a future version.

looking forward to it!

b0c5

Seems this option is not yet available in Zotero 7.

b0c5

This was recently requested again: https://forums.zotero.org/discussion/123009/set-default-file-to-open/p1

> 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?

EscPhilip

Indeed still interested in this too.
Best regards

ctm500

There have been a few websites (e.g., scienceDirect) where many times I have to manually download a published PDF and the default becomes a snapshot or a PMC / less-well-typeset version that Zotero can grab - I might seem nitpicky, but sometimes the open access PDFs have something irritating like figures all at the end of the PDF. Moreover, this means that if I have a professionally-typeset PDF, I have to manually remove the open-access version in order for my zotero-synced android ereader to default to looking at the good PDF.

Not a dealbreaker, this is still an awesome workflow, but it seems like an easy fix for a big quality-of-life improvement.

Daniel.A6

Just bumped into this problem.

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.

b0c5

Hello, any news on whether this feature will be available?

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.

vmarinkov

The default attachment is also needed for 3rd-party integrations like Obsidian.

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.

sunilel

This still is not implemented. Hope it comes soon!

psls

I would appreciate this feature as well.

b0c5

Ideally the setting should sync, so also in the mobile devices (iOS / Android) the selected attachment opens by default.

b0c5

> It will be possible to set a different primary attachment in a future version.

Any updates on when this will be available?

Pei Huang

Hi all,

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

gcarlet

It works for me, thanks!

sunilel

Sounds great, thank you for that!

b0c5

Does this plugin work also to set the default for mobile apps ?

m_chen

It works, thank you!

warguelles

there is only one function: right-clicking a PDF and setting it as the default file to open.

That sounds interesting! What does the plugin do to set a PDF as the “primary” one? Does it change the date?

alex_kent

(This is in reference to Pei Huang's zotero-default-attachment plugin.)

What does the plugin do to set a PDF as the “primary” one?

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 Zotero getBestAttachment function/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.mappings

Discussion

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.ts to remove that restriction (search for mentions of application/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.]

mjthoraval

@alex_kent: Thanks for the feedback. I have implemented a solution in the Weavero plugin: https://github.com/mjthoraval/Weavero
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.

alex_kent

@mjthoraval Interesting, I'll take a look. Storing the override as an attachment tag seems like a very sound, sensible, and robust approach.

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.)

mjthoraval

I try my best to test the code before releasing it.
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.