add new test for different articles from the same book in DuplicateCeckTest

[Luggas4you]

Adds a new test for #8885 to org.jabref.logic.database.DuplicateCheckTest which checks if different articles from the same book are duplicates.

Compulsory checks

Preview Give feedback

1. Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
2. Tests created for changes (if applicable)
3. Manually tested changed features in running JabRef (always required)
4. Screenshots added in PR description (for UI changes)
5. Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
6. Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[ThiloteE]

Do I understand this right that booktitle, editor, publisher, isbn and year have to be similar to count as excluded from duplicate check? If one of those 5 differs, then the merge duplicates dialogue will trigger? If one of these 5 misses, the dialogue will also always be triggered?

[Luggas4you]

Do I understand this right that booktitle, editor, publisher, isbn and year have to be similar to count as excluded from duplicate check? If one of those 5 differs, then the merge duplicates dialogue will trigger? If one of these 5 misses, the dialogue will also always be triggered?

I think so, I do not know yet, I was too quick requesting the commit ^^ I will have to do some more work in order to make this work.

[ThiloteE]

I tested this PR. Following entries trigger duplicate merge dialogue upon copying / pasting them into the same library:

@Article{article1,
  author    = {author1},
  title     = {title1},
  year      = {2000-01-01},
  pages     = {10-11},
  booktitle = {Book},
  chapter   = {1},
  date      = {2000-01-01},
  editor    = {editor},
  isbn      = {978-1-4684-8585-1},
  publisher = {publisher},
}

@Article{article2,
  author    = {author2},
  title     = {title2},
  year      = {2000-01-01},
  pages     = {20-22},
  booktitle = {Book},
  chapter   = {2},
  date      = {2000-01-01},
  editor    = {editor},
  isbn      = {978-1-4684-8585-1},
  publisher = {publisher},
}

[koppor]

I think so, I do not know yet, I was too fast requesting the commit ^^

You did a pull request, which is fine!

You are sharing information fast, which is also fine: "Move fast, break things" is the agile way of working. ^^

In the concrete case, the claim was that the issue #8885 was solved meanwhile. In general, all issue fixes should be covered by test cases - to have a machine-repeatable check. A machine-repeatable check frees us humas to click through JabRef. This pull request created a machine-repatable check for the issue. It turned out that the issue was NOT fixed. Thus, we need to really work on a fix.

@Luggas4you You can create an additional test case based on the data provided by @ThiloteE. This way, we also cover his case.

Depending on how we treat the difference between title1 and title2, this could also be treated as duplicate. Reason: If a title differs only in one letter, I would bet, it is a duplicate. Thus, maybe the test by @ThiloteE will really lead to a duplicate.

@Luggas4you used Performance on a Signal and Rest in Treatment as title, which are surely no duplicates.

More test cases:

• If Rest in Treatment and {Rest in Treatment} were used as the two titles, the entries should be considered duplicate
• If Rest in Treatment and {Rest} in {Treatment} were used as the two titles, the entries should be considered duplicate
• If Rest in Treatment and {R}est in {T}reatment were used as the two titles, the entries should be considered duplicate
• If Rest in Treatment and Rest in treatment were used as the two titles, the entries should be considered duplicate
• If Rest in Treatment and Rest inn Treatment were used as the two titles, the entries should be considered duplicate
• If Rest in Treatment and Restin Treatment were used as the two titles, the entries should be considered duplicate

[koppor]

Coming from #8885 (comment)

Entries may have the same isbn number, but not be the same entries.

Reason: A book has an ISBN number, but a book may contain multiple chapters by different authors. Each chapter can be an entry. This entry is not a duplicate.

[Siedlerchr]

I think the original reason was: If two entries have the same identifier they are most likely duplicates. e..g two articles with the same doi means you already imported that article.
But we did not check for books, that book chapter can have the same isbn. IMHO this is a use case for crossref. You but the isbn in the book entry and the inbook entrires of the chapter references this and will have their isbn also filled when citing

[koppor]

I think the original reason was: If two entries have the same identifier they are most likely duplicates. e..g two articles with the same doi means you already imported that article.

Yes.

But we did not check for books, that book chapter can have the same isbn.

This was overlooked at the implementation. One can even have two @inproceeding entries with the same ISBN but different chapters of a book. Without using crossref. This is, for instance, the case, if one collects two interesting publications of one venue. Such a venue could be ZEUS.

IMHO this is a use case for crossref. You but the isbn in the book entry and the inbook entrires of the chapter references this and will have their isbn also filled when citing

Yes! We currently lack of good support for crossref.

[Siedlerchr]

What is the status here? I like the idea of having extra tests, but I think the Duplicate manager does not yet take this into account. I think we can annotate the test with @ignore in the meantime and a description why it's disabled

[koppor]

I added the description now using the value parameter of @Disabled. I will add it to the merge queue to move things forward.

[koppor]

The GitHub workflows just seem to hang. At another occation, this was because the Workflow file was invalid. This is not the case here.

(Screenshot for archiving reasons)

Maybe, GitHub has issues, because the PR was opened before the merge queue was activated? Therefore, I try to close and reopen the PR.

[koppor]

Temporarily removed "Create installer for X" to required checks. They will be checked by the merge queue nevertheless. Trying now.

[koppor]

Note that the Deployment * checks do not appear in the list if these checks are not required any more. -- This is a hint that the trigger of the deployment workflow is not being activated. Maybe, we got something wrong there? However, I did not find something wrong...

[koppor]

Note: We configured the merge queue checks NOT to fail. Thus, PRs won't be merged if the installer cannot be build:

[Siedlerchr]

Mabye because it was a fork of jabref and therefore the build installer does not work/is skipped?

[koppor]

(For the interested readers)

Mabye because it was a fork of jabref and therefore the build installer does not work/is skipped?

I thought so too. I wondered, why it worked before the merge. I tried to re-create protection rules. Did not work. Then I came to the idea of triggers. See #10319 for the fix and the linked discussion for an explanation.