I have the same wish. Our company is already paying large sums for IT services that include network storage. It would make much more sense if the attachments (>10 GB) were stored on a shared network drive, and there was a link to each.

I have already the attachments stored locally in my Zotero storage dir, it would be extremely simple to change this into linked items by using Zotfile. In Zotfile, I would only need to set the storage directory to "Z:\Literature" and run an update on all items in the library. This network address is absolute and the same for all users so I don't see that this would be a problem across machines.

We still have the need for syncronizing the database, snapshots and notes, though.

there's no current hidden setting. Dan makes all calls on this, but I doubt he'll be willing to include this before relative links for groups exist. He has said that they'd accept patches for that.

relative links don't exist simply because it's very much not marginal/no cost to implement them. It's mostly UI/UX stuff, but that's not insignificant and would take a solid amount of time.

But you're simply wrong about simply allowing links to sync being costless: doing something that breaks links for 90% of all users--i.e. everyone without a locally shared harddisk with stable filepaths --is very costly, both in terms of the time wasted by frustrated users and the time we have to spend to explain the situation to them.

I can only tell you that Dan has been very clear about this and personally I think it's a reasonable decision:
Links for groups will be enabled as soon as we can expect them not to break things for a large share of users, i.e. as soon as relative links for groups work.

If you've ever read or been in an implementation discussion with Dan, you'll know that "we could add a hidden preference for this" is pretty much his least favorite phrase. He literally has a Tumblr called "Excessive Customization". Not everyone has to share that design philosophy, but it does have a lot of benefits on the user experience side of things, even if it does mean that you sometimes have to wait for a feature longer than you'd like.

I mean -- the easiest way would, of course, be to just use file storage. For an organization of any size, the costs of unlimited storage are negligible, so it's only privacy/security issues that might cause problems.

If you're set on using links, one way would be to have everyone working on a single Zotero account.

I don't think there's any other reasonable workaround.

When files are synced in groups with the file storage option, does that make one local copy of the file for each group member (plus the common online copy)?

yes.

Institutional plans seem to assign storage per person, which is not the correct solution.

correct, you would just buy unlimited storage for a single user (ideally not a person but an account held by the organization for this purpose only), the owner of the group. That's why I say the costs are negligible: it's $120/year for the whole organization. I just did a workshop for a small/mid-sized biotech company that are doing this with now several dozen researchers.

Doesn't help with the privacy issue, but note that you can set file syncing to only download files as needed, so there wouldn't be multiple copies except when requested. (There's no automated mechanism to delete locally cached files after a period of time, but that's something I'd like to add at some point.)

Dan, are you saying the file (e.g. PDF) will be downloaded only when the user tries to open it?

Yes. You just can't currently remove it automatically afterward, though you can do Show File and delete the file.

So, if one member of the group annotates a PDF doc, will that update the doc for all users of the group?

In download-as-needed mode, changed files are still uploaded, and files that have been previously downloaded should still be updated. (I haven't tested that recently, but that's how it should work.)

Is it possible to have the online storage encrypted, but local downloaded copies as not?

Encrypted client-side, you mean? It's something I've always been interested in offering, for both data and files, but there hasn't been a lot of interest in it — people generally say that their institutional policies prevent uploading data to external servers without making a distinction between unencrypted and client-side-encrypted data. Not sure if that's changed more recently.

1. The patch would become available to all Zotero users, not just you. Always hard to predict how long something like this takes. I'd say maybe two days for someone who really knows what they're doing: one for developing and testing, the other to adjust after feedback during code review. For someone who doesn't have a lot of dev experience and even for people who don't know much about Zotero's code base and style, that would go up a lot.


2. The full text search content syncs separately from the actual files. So the answer to your question is yes, you can search all full text even if you don't have any of the actual files locally.

Dan, Adam,

Thanks for the replies. I'm looking forward to seeing functionality such as this in Zotero one day, but I know that there are many requested functions. Anyway, keep up the great work, I've been a big fan of Zotero for several years now (and now people in my company are becoming fans as well...)

T.

Second that alastairhmoore. Any update on this? Thanks.

4 years later, still asking the same question. Looks like there's still no solution?

New Zotero user here, adding more support for this request. @ttlanckr and @simonssim , my organization's situation is similar to yours - would either of you mind updating us on how you and your organizations have used Zotero over the years since you raised this issue?

Have you found workarounds, used something other than Zotero, or tried writing a Zotero patch?

I'm trying to understand whether this issue is a low priority because (A) few Zotero users use Groups in this way or because (B) the technical obstacles require substantial time/money to overcome. If its B, then it seems that we and our respective organizations could contribute money to pay for the development. This is something @gurdas has suggested before in related discussions. Can anyone estimate a ballpark cost?

Zotero Groups functionality seems almost perfect for this kind of organizational collaboration and I would love to help get it all the way there.

Thanks for the update @dstillman. Unfortunately the GitHub patch link was incomplete. I think you're referring to this? Looks like Zotero is going through some important framework changes (XUL to HTML/React to Electron) before any new features can be added. Glad to see this essential but behind-the-scenes progress. Sharing this on a Public Zotero Roadmap would be cool.

While you're here, would you mind sharing your thoughts on the idea of Zotero feature requestors paying to expedite implementation of their request? I'm brand new to the Zotero community so I want to respect its long history and practices. Thanks!

Thanks for the quick reply @dstillman.

Am I understanding correctly that this patch - once its XUL prefs are rewritten as React/HTML - fulfills the need you described in your November 9, 2015 comment:

To clarify, the patch would need to be for Linked Attachment Base Directory support (and the UI to go with it) in groups, not just adding linked files. It's the former that's holding this back.

If that's correct, then it sounds like we're quite close to having the feature this thread is all about? From GitHub, it appears the patch developer was instructed to wait for Zotero core developers to finish redoing the preferences in React. Is there an expected timeframe for that redo?

Given that this feature has been requested by many users for at least 8 years, it's hard to understand why so many other new features have been added ahead of it. E.g., the recent Retraction Watch feature is nice, but was it far easier to implement or far more in demand?

In this context, it's understandable when users like @jsfzot wonder if the delay results from a potential conflict between Zotero's revenue stream and this feature. Personally, I'd prefer to make an annual donation to Zotero in support of its awesomeness, rather than pay a (reasonably small) fee for Zotero Storage. Cloud file storage seems like such a peripheral part of Zotero that it's strange for that to be its monetization. I have a hard time imagining the developers de-prioritizing feature additions because of this, but 8 years does seem unusually long.