Missing Import all Entries and dealing with Duplicates

[alfureu]

JabRef 5.2--2020-12-24--6a2a512
Windows 10 10.0 amd64
Java 14.0.2

• Mandatory: I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

This issue is present on the v5.2 stable.

Steps to reproduce the behavior:

1. Import a .bib file
2. Offered options are: Select all new entries or Unselect all (see screenshot)

There should be an Import all button, which is now missing. JabRef is then capable of identifying the duplicates and getting rid of them later. It is important to have the import all for later scrutiny and calculations for, e.g. literature reviews.

[alfureu]

In addition to this issue, please find below a 1st hand experience from a person conducting a systematic literature review (SLR). When conducting SLR, one scrapes multiple databases, and in an iterative way one has to report the number(s) of results, including and excluding duplicates.

The issue is that currently JabRef (v5.2) does not help in sorting and counting these duplicates. It facilitates relatively effectively the elimination of duplicates. However, there should be an option how to temporarily preserve the duplicates and eliminate them at a later stage in order to be able to conduct SLRs.

Suggestion no.1: Please add an option "Do not add anything" to this part. This will enable the user to easily identify potential duplicates based on the citation key generator (e.g. if one creates a citation key based on, e.g. 1stauthor_1stword_year).

Suggestion no.2: In the earlier versions of JabRef 3.4 (I believe) there was an option to highlight entries in the entry table with red colour in case they were considered duplicates (based on citation keys). It would be great to visually "see" the potential duplicates. Currently it is not possible.

Suggestion no.3: JabRef is pretty powerful in identifying potential duplicates, by adding the 'a', 'b', 'c'... letters (or not, as suggested above). There should be an option to create an automatic Smart Group listing all the potential duplicates in one place for further operations, listings, exclusion, etc. (something along the lines of intersection / union mode), It would improve conducting SLRs immensely.

Hope these are helpful suggestions.

[calixtus]

Thanks for your suggestions. Indeed, they are helpful, although they probably need some more investigation as we have a powerful SLR feature already on the edge of shipping. Our newest core developer @DominikVoigt has spent a lot of time on this, and I suggest the he takes a closer look, what makes sense to include in relation to this new feature and if - how to include this.

[kristofmeixner]

It is not a duplicate issue but closely related to SLRs.

I have the issue that when merging entries oftentimes the 'higher' bibtexkey is preselected than the lower.

The way I conduct duplicate count and detection for SLRs is 1. assigning generated bibtexkeys, 2. merging or deleting duplicates & 3. diffing the original set of bibtexkeys with the cleaned set.

[github-actions]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!