Convert attachments to web links in public libraries

aurimas

I don't think I've seen this mentioned yet. Please link to relevant discussions though.

Currently, when an item with an attachment is moved to a public library, the attachment is removed. It may be more helpful if, where possible, the attachment were converted to a link attachment, which links to the PDF/document on the original website (this URL is stored with the attachment already anyway).

Here's my use case: I keep my library private, but was asked to share some literature on a topic. So I decided to go with a public library and move the relevant literature to a collection. I have PDFs attached to all of my items and would like to make it easier for my colleagues to find these PDFs. Since I can't share files directly, it would be a great alternative to provide links to PDFs (actually, I don't even want to share the PDFs I have, since they have been annotated). Access is not an issue in my case, since I am sharing within my institution, so I expect them to be able to view these online.

So basically, I think that if an attachment came from a webpage, instead of discarding it, we should just convert it to a link.

Edit: though, of course, this doesn't work with all websites (i.e. session cookies)

dstillman

Yeah, that's a great idea. (In technical terms, we'd be copying imported-file attachments as linked-url attachments when the group doesn't allow file editing.)

Re: session ids, we should really try not to save those to begin with.

aurimas

Re: session ids, we should really try not to save those to begin with.

I don't think we can avoid this. The URLs I'm referring to are the ones we pass from translators for file attachments. Some will be session/cookie specific, others will be stable. It's sort of the luck of the draw.

Thinking some more about this, what if group file attachment restrictions were controlled at sync level? Right now, the client prevents file attachment copying to public groups. What if the client were to allow this, but during sync, the files would not be synced, just metadata? A few advantages:

1) It would make it very easy for users to convert a group from public to private and essentially enable file sync even after having already dragged some files to the group library. Once the group is converted to private, the attachments would sync.

2) Since metadata would be synced, you wouldn't need to convert imported-file attachments to linked-url attachments. Zotero server would be able to use the origin URL of the attachment, instead of the file itself when displaying a link on the website.

The disadvantage is that it would be less obvious that some files are not syncing, since the attachments would appear locally and would be displayed on the web, but would (sometimes*) fail to open on other computers. (*sometimes, because the client would maybe also be able to open the attachment directly from the website instead of the local file?) However, in this case, I would argue that the user would have wanted to sync attachments, in which case we're back to (1).

One actual downside that I can think of is disk space usage. Say the user will never want the group to sync file attachments. In that case, when the user drags file attachments to the group, the files would be copied locally and would take up extra space.

Alternatively, perhaps some simple guidance dialog would be sufficient (and more transparent). When items are dragged into a group for the first time, the user is notified that this is a public group and file attachments are not allowed. He would then be given the option of converting file attachments to linked-url attachments or discarding them altogether depending on the needs of the group.

</brainstorming>

adamsmith

Thinking some more about this, what if group file attachment restrictions were controlled at sync level?

I certainly see the advantage, but I'd be much more concerned than you about the confusion it causes.

dstillman

Yeah, that seems way too confusing to me. Things that are synced should be synced — there shouldn't be a different state on one computer than all the others just by a fluke of where the file was added.

aurimas

It would be the same situation as someone running out of storage space on the server

dstillman

But that triggers an error message every time saying what the problem is and how to resolve it. It's not a normal condition.

aurimas

Expecting to sync files in a public group is also not a normal condition (and, to the user, losing file attachments when transferring to a group library isn't normal either). This would just prevent having to re-drag all of the items to the group library

aurimas

But I think I agree that there's probably a better way to solve this.

Dan, is it possible (or could it be made possible) to alter group settings via api? It would also be great to create groups directly from the client

dstillman

That's currently a private API. We could potentially create a public one that's accessible by the group owner, but I'm not sure it's worth it, since we'd then have to maintain interfaces in multiple places to accomplish the same thing. We could, however, do a better job of sending people directly to the appropriate settings pages.

Creating a group via the client is probably not going to happen. It'd be a pretty significant duplication of work and require lots more API stuff exposed (e.g., user searching), most of which either is currently restricted to access from www or only happens on www and doesn't touch the API to begin with.

I think the drag is the right place to warn about this. If we offer a convert-or-ignore preference, we can store the preference in the (unsynced) 'settings' table and clear the entries on group deletion or mode change.

We also do have a file sync error dialog already if files exist in a group that doesn't allow them and the user tries to sync. Right now I think that offers to reset the group, which is overkill and can cause other sync problems. It should instead offer the ability to convert the existing imported-file attachments to linked-URL attachments, but we need code to create those copies in order to do that.

aurimas

but I'm not sure it's worth it, since we'd then have to maintain interfaces in multiple places to accomplish the same thing.

Idk if that's a great reason not to do it. There are multiple interfaces to add items to the library. The group creation interface is fairly simple. All it has is group name and privacy/membership settings. Once the group is created, I guess inviting someone to group could also be a neat feature to have locally. That could be implemented incrementally and initially would simply open an appropriate web pages.

Creating a group via the client is probably not going to happen. It'd be a pretty significant duplication of work and require lots more API stuff exposed (e.g., user searching)

I don't follow what user searching has to do with creating a group. Do you mean that you would want to check if a given group name has already been taken? I would expect the API to simply return an error in that case and then client can respond appropriately.

Of course this feature would have to be disabled where an internet connection is not available. Or the user could be prompted to change the name of the group once the internet connection becomes available (yes, this is very messy and I don't like it either, but it is convenient for the user, since he/she does not have to wait for an internet connection to start putting together a group library)

I think the drag is the right place to warn about this.

My idea was to give user an option of converting a public library to a group library when he/she drags a file attachment for the first time. Ideally this would be a single click of the button, but if the API is not going to happen, we could just cancel the drag operation and open up the appropriate web page (that's a good start anyway).

dstillman

I don't follow what user searching has to do with creating a group.

Once you create a group, the first thing most people want to do is invite members to it, which for technical reasons would be very complicated to add to the client, among other things because it doesn't come from the API at all. Creating a group from the client would be relatively straightforward, but if you can't invite members, I don't think there's a point to creating from there.

Or the user could be prompted to change the name of the group once the internet connection becomes available (yes, this is very messy and I don't like it either, but it is convenient for the user, since he/she does not have to wait for an internet connection to start putting together a group library)

Yeah, there's no way we'd allow group operations without an internet connection. Allowing personal libraries to exist without server library ids already adds a huge amount of complexity to the client — doing that for groups would be even more complicated. A group name or metadata change could in theory be queued and synced, but we'd have to deal with conflicts, files could be synced to the server before setting changes went through, etc. Adding all of that complexity would be crazy. People can create a temporary collection locally and create the group when they're online.

My idea was to give user an option of converting a public library to a group library when he/she drags a file attachment for the first time.

Right, I know. But thinking about this further, I don't think we can even do that, since we don't want to allow any API key of an owner's that can write to the group to be able to change the settings, and I don't think we want to add a separate API key setting for this. It also seems like a fairly dangerous operation to allow via the API, since a simple settings change can delete lots of files as a result.

we could just cancel the drag operation and open up the appropriate web page (that's a good start anyway)

I think we can show a warning dialog that explains that files imported from websites will be converted to web links and imported local files will be omitted, with options to "Continue", "Cancel", or "Change Group Settings…", with the last one opening the appropriate settings page on the site.

aurimas

I think we can show a warning dialog that explains that files imported from websites will be converted to web links and imported local files will be omitted, with options to "Continue", "Cancel", or "Change Group Settings…", with the last one opening the appropriate settings page on the site.

Precisely. That would be very helpful.