Add option to disable autolink files

[AEgit]

I am not sure whether this counts as a feature request or a bug.

JabRef 5.0-dev--snapshot--2019-07-06--master--add35be12
Windows 10 10.0 amd64
Java 1.8.0_211

In JabRef 3.8.2 it was possible to link previously downloaded PDFs to the database item using the "Get fulltext" button (see http://help.jabref.org/en/GetBibTeXDataFromDOI), if you had set a main file directory (http://help.jabref.org/en/FileLinks). In current development versions that does not appear to be possible anymore. Instead, JabRef apparently starts to automatically look for all files whose names start with the bibtex key (depending on your setting) and then allow you you add these files. I would prefer that this automatic behaviour was turned off (or if people like it, that there is at least a way of turning it off) and that the manual addition becomes possible again with a dedicated button.

If you have many supporting files the automatic behaviour auto file link behaviour can become a bit annoying, especially if you have Bibtex keys like the following "Berner2013" and "Berner2013_Test" (all the supporting files of "Berner2013_Test" will automatically show up for "Berner2013").

Furthermore, I have the impression that JabRef no longer checks just the main file directory (as it did in version 3.8.2) but seems to scan the whole file system? Can you confirm this? If that is the case, can you restore the old behaviour: I don't want to link PDFs that are not found in the dedicated PDF folder.

[Siedlerchr]

Hi,

you are right. Get fulltext only searches online, not local. This was on purpose. There is somewhere an issue about that.
You can however use Quality-> Automatically set file links for the selected entry.

The auto link behavior can be configured in the prefs -> File tab:
Autolink files that start with or exactly match the key or alternatively a RegEx.

However, there is currently no option to disable this feature for the entry editor,

Furthermore, I have the impression that JabRef no longer checks just the main file directory (as it did in version 3.8.2) but seems to scan the whole file system? Can you confirm this? If that is the case, can you restore the old behaviour: I don't want to link PDFs that are not found in the dedicated PDF folder.

JabRef checks the following directories:
// 1. library properties user-specific directory
// 2. library properties general directory
// 3. preferences directory
// 4. BIB file directory (if the option use as primary directory in the global prefs is checked, than this dir is searched first and takes precedence over all others)

I hope this helps to clarify the feature a bit.

[AEgit]

@Siedlerchr
Thank you for the explanation. Ok, so Quality -> Automatically set file links (or alternatively pressing "F7") will set the file links for the selected entry, is that correct? Or will it set the file links for ALL entries of the database?
If it is the former, I am ok with it: The functionality that "Get fulltext" originally provided has just been moved to another menu (I would say maybe less intuitive, but I reckon there are reasons) and it can even be used with a keyboard shortcut. If it is the latter, though, then the manual assignment of links for a SINGLE entry is still missing - I would really like to see that implemented in that case.

It would be nice, to disable the automatic autolink feature in the entry editor, since it can get quite confusing when you have lots of files, especially those that start with the same bibtex key.

Furthermore, the file row in the "General" tab of the entry editor should display more rows. Here an example of the same entry with JabRef 3.8.2 and JabRef 5.0:

JabRef 3.8.2

JabRef 5.0

As you can see, in the case of JabRef 5.0 only 3 rows are shown in the "File" part of the "General" tab. The rest can only be reached by scrolling down. In JabRef 3.8.2 all files are shown. Note, that in this case JabRef has been opened on a 40'' screen (4k) at max window height so this is definitely not an issue regarding the size of the monitor or its resolution. Rather, the standard settings for displaying things in the various entry editor tabs need some revamp (I think this applies to a couple of rows in the entry editor, but for now, this is the one I have spotted).

Thank you also very much for clarifying the way JabRef searches for linked files. Ok, in this case I will have to think about my current folder setup and where to store the JabRef database relative to the file folder.

[AEgit]

JabRef 5.3--2021-03-05--f7de0a6
Windows 10 10.0 amd64
Java 14.0.2
JavaFX 15.0.1+1

The issues and feature requests described in #5105 (comment) and #5105 (comment) still persist.

[ThiloteE]

Not relevant anymore:
I can confirm that automatically set file links (or alternatively pressing "F7") will set the file links for the selected entry(s).

Still relevant:
The file row in the "General" tab of the entry editor should display more rows indeed. Still relevant.

JabRef 5.4--2021-10-15--93b8025
Windows 10 10.0 amd64
Java 16.0.2
JavaFX 17.0.0.1+1

[ThiloteE]

Closing in favour of #8823 so that we don't have two issues for the same thing.

[claell]

@ThiloteE only the comment (#5105 (comment)) seems to be mentioning the same topic. The issue here is about something else. So I suggest reopening this 😃

[ThiloteE]

Most of the issues that were mentioned in this issue are now adressed, right @AEgit? See #5105 (comment). The only remaining item seems to be about the file field.

Are there some other concerns?

In general:

• This issue is quite old
• it takes time to disentangle what already is implemented and what is not.
• we have another issue that is about the same thing. Before I opened the new Issue, I searched for similar issues and did NOT find this issue, because the name of this issue is very generic. I have never used old JabRef, so it never rang a bell that I should look into this issue to see that somebody already called to fix misaligned files field. Yes I know I have commented here before, but my memory can contain only so much...

In my opinion, it makes sense to leave one of them closed and to open a new issue for the things that remain.

[AEgit]

@ThiloteE Sorry for the delayed response. The only thing that remains (besides the small size of the file field, see also the new isssue: #8823) is the suggestion to allow again the user to disable the automatic autolink feature in the entry editor. The reason being that since it can get quite confusing when you have lots of files, especially those that start with the same bibtex key. It is difficult to asses, how much of a problem this will remain, once the size of the file field has been increase (at the moment it is just unusable if you have multiple linked files). I reckon increasing the size of the file field will alleviate the issue, but it will still be a problem if the user cannot manually turn of the automatic autolink feature.

[ThiloteE]

If you have many supporting files the automatic behaviour auto file link behaviour can become a bit annoying, especially if you have Bibtex keys like the following "Berner2013" and "Berner2013_Test" (all the supporting files of "Berner2013_Test" will automatically show up for "Berner2013").

refers to issue #8152

Workaround:

To alleviate the problem of having very similar bibkeys that are then found via the default search pattern, I would suggest to create unique (e.g. DOI) and/or complex citationkeys for your entries and also use these as names for your files. (Refining the search pattern would likely be necessary.)

See here:

There is another preference to name the files from the web.

[ThiloteE]

Sorry, I am a little lost and fail to understand how you want (and why it would be better) to disable showing files that were found via "automatic file links", if you want to CONTINUE using "automatic file links"...
If you don't want these files to show, just disable automatic file links. Would that not suffice? Edit: that is the problem. It cannot be disabled. I thought one could.

Current behaviour (as in JabRef 5.6):

• Files that are found will show, but are not automatically linked. Clicking with mouse button on the found file in the general editor tab will link the files. Also, selecting entries and usingQuality > Automatically set file links (F7) will link the files.

Ideas about alternative behaviours:

• Files that are found will not show in the entry-editor and are not automatically linked. How to auto-link files? Use Quality > Automatically set file links (F7).
  • Not good, because it will still link files like "Berner2013_Test"
  • Not good, because users will not even notice they will link "Berner2013_Test" before it is too late.
  • Good, because I could imagine it increases performance of JabRef with large libraries.

[ThiloteE]

Right ... there IS no preference that allows to disable automatic file links... sorry, my bad.

[AEgit]

To alleviate the problem of having very similar bibkeys that are then found via the default search pattern, I would suggest to create unique (e.g. DOI) and/or complex citationkeys for your entries and also use these as names for your files. (Refining the search pattern would likely be necessary.)

Not feasible for a JabRef database with thousands of entries (and as mentioned previously, in the old JabRef implementation this was not an issue). Furthermore, there are certain instances where you even want to manually link files that do not conform to the bibtex key (yes, there are reasons for that, but I will not bother people with why that is the case).

[AEgit]

Right ... there IS no preference that allows to disable automatic file links... sorry, my bad.

Yep, that is an issue.

[ThiloteE]

To alleviate the problem of having very similar bibkeys that are then found via the default search pattern, I would suggest to create unique (e.g. DOI) and/or complex citationkeys for your entries and also use these as names for your files. (Refining the search pattern would likely be necessary.)

Not feasible for a JabRef database with thousands of entries [...]

Why? Is regular expression search too slow?

Btw.: one CAN manually link files that do not conform to the bibtex key. It is that tiny + button at the right side :-)

[AEgit]

Imagine you have a (massive) JabRef database where thousands of items have very similar bibtex keys, the latter of which also go into the thousands. I am not sure how a regular expression search would help you there, if you have to repeat it for thousands of bibtex keys. I see, how this would work, if you just have a handful of similar bibtex keys (and maybe thousands of entries sharing those similar keys), but otherwise this seems a very laborious job. And mind you, a job that is only necessary, because a feature that was present in an older version of JabRef was dropped in a newer one. Or maybe I am missing something and it would be pretty straightforward to do (but how then?)?

Btw.: one CAN manually link files that do not conform to the bibtex key. It is that tiny + button at the right side :-)

Cheers, since I still have to rely on version 3.8 for my daily work, I am not up to date with the functionality of the newer version all the time ^^

[ThiloteE]

If you have many supporting files the automatic behaviour auto file link behaviour can become a bit annoying, especially if you have Bibtex keys like the following "Berner2013" and "Berner2013_Test" (all the supporting files of "Berner2013_Test" will automatically show up for "Berner2013").

Workaround:

To alleviate the problem of having very similar bibkeys that are then found via the default search pattern, I would suggest to create unique (e.g. DOI) and/or complex citationkeys for your entries and also use these as names for your files. (Refining the search pattern would likely be necessary.)

Not feasible for a JabRef database with thousands of entries (and as mentioned previously,

Why?

Imagine you have a (massive) JabRef database where thousands of items have very similar bibtex keys, the latter if which also go into the thousands.

The workaround would be to:

1. create very complex bibtex keys, so that there is only a very small chance that keys happen to be or become similar. This can be done in options > preferences > citation key generator > key patterns
   

   My complex pattern is for example:
   [shortauthor:([authEtAl:([organization:([institution])])])][date:([year:([urldate])])][shorttitleINI:lower], but I might replace this pattern at one point with one that includes the DOI. Am not there yet :)

   Regardless of the pattern you choose, the main aim of this step here is to get rid of short bibtex keys like Berner2013 and replace them with something more unique.

2. Select all your entries and change their key to the above pattern via this button:
   

3. Then, you could rename your files to include these very complex bibtex keys.
   I believe you need to set a pattern in options > preferences > Linked Files > Linked File Name Conventions
   
   The actual renaming can be done via Quality > Cleanup Actions
   

   Be aware: Unfortunately, it is required that files are linked to the correct JabRef entries before the process of renaming starts! Renaming becomes complex if files are linked to multiple entries AND/OR are linked to "wrong" entries.

   That means, that this whole workaround is not feasible and not advised to be used on a database that is in an unorderly and unmaintained "fresh" state.

4. Then you set a regular expression search in options > preferences > Linked Files: Autolink Files: Use Regular Expression search to find files adhering to this complex pattern. Here, you can choose to search for the bibtex key, which might probably be the easiest choice.

Voilà, "linked file search" will only show you specific files to attach. Very unrelated files will not show up anymore.

I think the above described workaround is worth giving a shot @AEgit

And yes, it is just a "workaround". Not a complete solution to the problem you describe. Sorry, I am not a programmer, so I personally mostly can only help coping and prepare the groundwork for the real superheroes here at JabRef :D

Additional Comments:

With regard to renaming fields or more specific: adding the bibtex key to content of other fields (e.g. the "file" field):

The new "Automatic field editor", which HoussemNasri is working on, can copy from one field to another, but it is not yet possible to choose where exactly the keyword will end up within the field. Usually, it will end up at the end of the field or there is the option to completely overwrite the field content altogether. Therefore, if we were to use this, it would destroy the file path.

Before we ask for yet another new feature, I propose to test if the above workaround works though :D

Of course, before you try this, I would suggest to make a backup of your library and a backup of your attached files!

[AEgit]

@ThiloteE Thank for your very detailed explanation of the workaround your propose! I appreciate your effort, but unfortunately in my case this will not work. I will detail below why that is the case.

1. create very complex bibtex keys,

I like the simple bibtex keys I have, but more importantly I am writing on a document (containing thousands of references) that relies on the JabRef database and is updated almost simultaneously to the JabRef database. This means, that, if I were to change lots of JabRef bibtex keys I would also have to change all the according references in the document, which use those keys. Since this document is unfinished (and will - by the nature of it - never be finished), I cannot just save the old JabRef database for the document and then apply the suggested changes to just a newer version of the JabRef database.

3. Then, you could rename your files to include these very complex bibtex keys.
   [...]
   Be aware: Unfortunately, it is required that files are linked to the correct JabRef entries before the process of renaming starts! Renaming becomes complex if files are linked to multiple entries AND/OR are linked to "wrong" entries.

I have several files that are linked to multiple entries - those are not linked to "wrong" entries and the state of the database is also not "unorderly". The choice to link them to multiple entries has a purpose. If you are dealing with biology articles from the 19th century, you want to link both the actual article AND the complete volume to your JabRef items (I will not bore people with the reason for this). Obviously, these volumes will be linked to multiple JabRef entries. So, you need these files to be linked to multiple entries - the only alternative I could see here, would be to create a separate copy of the volume for each entry, which would come with a prohibitive storage space cost.

I would like to point out, that the thing I suggest is not really a new feature - this was already present in older JabRef versions. The feature was just lost in the newer versions.

Nevertheless, thanks again for your effort! I reckon for other databases your workaround would potentially solve the problem.

[AEgit]

The automatic autolink feature has now been tackled in:
JabRef 5.10-PullRequest9903.905--2023-05-16--f582ebd
Windows 10 10.0 amd64
Java 20.0.1
JavaFX 20+19

This release appears to have fixed the problem - I will report again, when this fix is part of the main branch.

[AEgit]

JabRef 5.10--2023-05-17--e6a2d4c
Windows 10 10.0 amd64
Java 20.0.1
JavaFX 20+19

I can confirm that disabling the "automatic autolink feature" is now possible in the current dev version. To disable the autolinking go to File -> Preferences -> Entry Editor -> Remove the tick for Automatically search and show unliked files in the entry editor

Well done!