-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Add check for existing crossrefs when importing entries into a library #11922
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your code currently does not meet JabRef's code guidelines.
We use Checkstyle to identify issues.
The tool reviewdog already placed comments on GitHub to indicate the places. See the tab "Files" in you PR.
Please carefully follow the setup guide for the codestyle.
Afterwards, please run checkstyle locally and fix the issues.
You can check review dog's comments at the tab "Files changed" of your pull request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left some small comments on your PR, but probably you also need a review from main maintainers, as I haven't fully understood the original issue
Thanks for the comments @InAnYan, I'll take a look through and update the key generation logic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strange change...
Did you test it?
finalizedEntries.addAll(entries); | ||
generateKeys(finalizedEntries); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the list? What happens on a second import of other entries? Will the citation keys of the previous entries be replaced?
I tested this change manually with a few different inputs and variations (e.g importing crossreferenced entries at the same time in different orders, importing them in different imports etc.). It worked with all key patterns I tried as well as for general use. I used a list since in practice entries are imported and have keys generated one at a time, so adding them to a list as they are imported and then generating keys on all of them at the end is the best way of ensuring crossref relationships are respected in terms of citation keys. Currently if a second import occurs the list will be maintained, but if old keys should not be regenerated that's an easy fix as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add two tests to org.jabref.gui.externalfiles.ImportHandlerTest
One where the List
of entries has the cross-refernced entry first, the other where it comes second.
Ensure that the citationkeygenerator is active. (This is a harder one, because the test currently does not have the citation key generator enabled).
This is crucial to automatically check that the poster's issue is resolved:
I would suggest to remove the variable finalizedEntries
and directly pass entries
to generateKeys
as I don't see any additional value of this variable.
@@ -76,6 +76,9 @@ public class ImportHandler { | |||
private final DialogService dialogService; | |||
private final TaskExecutor taskExecutor; | |||
|
|||
// list is filled as each entry is passed to importCleanedEntries | |||
private final List<BibEntry> finalizedEntries = new ArrayList<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rename list to addedEntries
. finalized
is a strange word.
Also remove final
keyword, because the list itself is modified; thus final
is misleading.
I think, this change is required because of our update at #10741 to org.jabref.gui.externalfiles.ImportHandler#importEntriesWithDuplicateCheck -- now, entries get added one by one and not as complete list. - This PR reassembles the complete list. @Siedlerchr I don't see a better solution for now. Do you? |
I have made the requested changes and added tests, so everything is now working correctly. However, I have noticed something unusual. The previous case which worked correctly before my changes (parent first, then child) no longer works correctly with a single call of generateKeys, as it seems like some other commit has caused issues with crossref inheritance. Calling generateKeys a first time across all entries before they are added to the database (in importEntriesWithDuplicateCheck) resolves this, so it's a small issue, but I just wanted to point it out. |
LOGGER.debug("not first entry, not pref flag, break will be used"); | ||
importEntryWithDuplicateCheck(database, entry); | ||
LOGGER.debug("not first entry, not pref flag, break will be used"); | ||
importEntryWithDuplicateCheck(database, entry); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong indent.
I do not understand. Is there a test case for it? - You moved |
There is a test case for it and it passes. I had to make some small adjustments to my implementation, but my tests pass and everything is working as expected. |
…/jabref into fix-for-issue-11136
Any hint which concrete test case it is? I need more time to understand the "small issue" and what needs to be done. I understand: With your PR: Something is broken which is not broken before. |
To review:
Maybe adjust the test text of #11136 (comment) - it seems to be incomplete.
Tests are existing at src/test/java/org/jabref/gui/externalfiles/ImportHandlerTest.java. But the "smal lissue" described at #11922 (comment) is unclear to me. |
The test case is
It was originally the case that when a parent was imported before a child it used to work before I made any changes, but this stopped working. I made an adjustment to my code so it works again, by initially calling
I have done all of the above and everything is working as expected. I also tried a number of key generation patterns ([year][auth], [title][year] etc.) as well as using my own test data. The parent's year is used correctly for the child's key no matter the order of import/state of the libraries. |
Strange change. The entries pasted should have working referencing keys. If it only works after an update, something is wrong probably somewhere else. |
Please be aware that you should only generate keys if the preferences are set but I think that generateCitaitonKeys already has a check |
Already handled: private void generateKeys(List<BibEntry> entries) {
if (!preferences.getImporterPreferences().isGenerateNewKeyOnImport()) {
return;
} Our method name is not that good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does not work at all.
The Crossref
value is NOT updated on key generation. This needs to be fixed.
org.jabref.logic.citationkeypattern.CitationKeyGenerator#generateAndSetKey
needs to be modifiered to return a List<FieldChange>
. (List is empty on no change)
org.jabref.logic.citationkeypattern.CitationKeyGenerator#generateKey needs to be adpated to go through this.database.getEntries()
and check crossref
of each entry. If it is the old key: replace with new one and break.
You can try out with following entries - there is no year
used for citaton key generation on paste for the second article.
@Article{parent,
author = {first-author},
year = {2024},
}
@Article{,
author = {third-best},
title = {title},
crossref = {parent},
}
Thus,
I think, citaton keys are properly updated using the |
Closing this issue due to inactivity 💤 Please ping us if you intend to resume work on this one. |
Before:
After:
This PR fixes #11136
Mandatory checks
CHANGELOG.md
described in a way that is understandable for the average user (if applicable)