Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look up fulltext documents does not link existing PDFs #3874

Closed
stefan-kolb opened this issue Mar 22, 2018 · 11 comments · Fixed by #5667
Closed

Look up fulltext documents does not link existing PDFs #3874

stefan-kolb opened this issue Mar 22, 2018 · 11 comments · Fixed by #5667
Labels
good first issue An issue intended for project-newcomers. Varies in difficulty. hacktoberfest Hacktoberfest tag. See https://hacktoberfest.digitalocean.com/faq/ for details. type: enhancement

Comments

@stefan-kolb
Copy link
Member

It looks like the autolink functionality does not work as expected anymore:

  1. I already have a file starting with the correct BibTeX key in my PDF repo
  2. It still downloads the file from the web

I expect to pick up the file from the PDF repo instead.

@stefan-kolb stefan-kolb added the bug Confirmed bugs or reports that are very likely to be bugs label Mar 22, 2018
@stefan-kolb
Copy link
Member Author

stefan-kolb commented Mar 22, 2018

Instead I get this icon in the file tab:
image
When I hover it says it found the PDF and if I want to accept it.
However, this is

  • hardly recognizable
  • it still downloads the new PDF in the background

This is a little bit akward.

@stefan-kolb
Copy link
Member Author

stefan-kolb commented Mar 22, 2018

I guess if we find a matching paper we can just add it without further user confirmation, as it is configured like that in the preferences.
@tobiasdiez I guess you implemented that, maybe you can help?

@tobiasdiez
Copy link
Member

Yes, I implemented that automatically found files are displayed in the entry editor. The display is indeed a bit irritating and we should improve it (tracked in #3607).

I don't understand why "auto-link" should download PDF's at all. We have a different button/menu entry for fulltext download, this should suffice.

@stefan-kolb
Copy link
Member Author

Ah sorry, I mean Quality - Look up fulltext documents. The former behavior was:

  • PDF already found link it instead of download it a new.

@stefan-kolb stefan-kolb changed the title Autolink files does not work Look up fulltext documents does not link existing PDFs Mar 22, 2018
@tobiasdiez
Copy link
Member

Ok, I can't remember I changed anything there but I do like the new behavior better and find it logical. If I click on "Look up fulltext document" I expect that JabRef downloads the fulltext for me regardless of whether there are already files linked or not.

@stefan-kolb
Copy link
Member Author

Hm, well we could leave it in such a way but then downloa full text would be more appropriate than lookup.
Also, it means two steps for the users. Try to autolink files, iff not found download files.
Formerly, this was integrated in one step.

@Siedlerchr
Copy link
Member

+1 for Looking up Fulldocuments should first try to search autolink file.
If not found -> Download from web

@stefan-kolb
Copy link
Member Author

This is important as a user cannot know if a file already exists in some subfolder for example and then downloads it again.

@stefan-kolb stefan-kolb added this to the v4.3 milestone Apr 26, 2018
@koppor
Copy link
Member

koppor commented May 30, 2018

Just a wild guess: It could be #3368 (not reviewed by me) and the follow-up fix #3509 (think, slightly reviewed by me).

@stefan-kolb stefan-kolb added type: enhancement and removed status: devcall bug Confirmed bugs or reports that are very likely to be bugs labels Jun 1, 2018
@Siedlerchr Siedlerchr added good first issue An issue intended for project-newcomers. Varies in difficulty. hacktoberfest Hacktoberfest tag. See https://hacktoberfest.digitalocean.com/faq/ for details. labels Oct 2, 2018
@Siedlerchr Siedlerchr removed this from the v4.4 milestone Oct 2, 2018
PedroPerozin added a commit to PedroPerozin/jabref that referenced this issue Jul 11, 2019
PedroPerozin added a commit to PedroPerozin/jabref that referenced this issue Jul 11, 2019
PedroPerozin added a commit to PedroPerozin/jabref that referenced this issue Jul 11, 2019
Siedlerchr added a commit that referenced this issue Aug 24, 2019
…xlookupfulltext

* 'master' of git://github.com/PedroPerozin/jabref:
  Change variable name Issue#3874
  Fix import order Issue #3874
  Fix checkstyle Issue #3874
  Fix travis
  Fix issue #3874
@koppor
Copy link
Member

koppor commented Aug 25, 2019

Do we have a "force-download" button?

Currently, I think, the common usecase is that one has one PDF for one entry. I am aware that sometimes, one collect's author copy, presentation, publisher version, ...

Maybe, the file handling can be improved in general... Giving "types" to file entries. Not the media types, but the semantic types (author's copy, publisher, draft, submitted, ...)

Refs #98 somehow

@tobiasdiez
Copy link
Member

I've thought a bit more about this and now I'm more convinced than ever that we should change the name of the action to "Download full text" (as @stefan-kolb proposed) instead of changing the current behavior. I think there are mainly the following uses cases:

  • The user created a new entry based off some source (e.g. website). In this case, he just wants to download the pdf (as there is no local file). It would be not harmful to look for a matching local pdf first, because it does not exist (in this use case).
  • The user just downloaded the pdf (and renamed it) and the database already contains a matching entry. In this case, the user wants to simply link the new file. If the linking fails (e.g. because the name of the pdf was slightly off) and we would change the behavior, JabRef then downloads a new pdf and the user now has two files for the same entry. Not what he wants. Instead it would be may more helpful if JabRef would realize that there is a similarly named file and propose to link that...
  • The user has an entry and does not remember if he already downloaded the corresponding pdf. In this case, he wants to first look for a local pdf and if that does not exist search for an online full text. For this use case, the new behavior would be perfectly fitting. However, it is also currently very easy to proceed: just open the general tab of the entry and you see if JabRef finds a local file (it would be shown in the list of files). Depending on that the user can accept the link or download the pdf.

Thus, the only advantage of the new behavior is saving a single click in the last use case. At the cost of a (in my opinion) somewhat confusing and complex feature. It definitely needs further explanation (since nobody would guess that Lookup = local lookup + online download). Thus, in summary, I'm strongly in favor of a simple "Download full text" feature that everybody understands when reading the action name. Long live "Do one thing, and do it well" ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue An issue intended for project-newcomers. Varies in difficulty. hacktoberfest Hacktoberfest tag. See https://hacktoberfest.digitalocean.com/faq/ for details. type: enhancement
Projects
None yet
4 participants