Support customized entry types in BibliographyConsistencyCheck

[koppor]

(This is a follow-up to #13584)

We have a library consistency check for checking whether fields in a set of entries are set/unset consistently. Currently, this is aware of the difference of BibTeX and BibLaTeX, but not Custom Entry Types

⚠ This is a good excercise to learn test-driven development and using a data model. This issue cannot be solved with an AI. You really have to think though BibTeX and BibLaTeX for yourself! Take this issue only if you are willing to invest significant time. ⚠

Example entry - from https://dblp.org/rec/journals/sqj/IftikharBAK25.html

@article{DBLP:journals/sqj/IftikharBAK25,
  author       = {Umar Iftikhar and
                  J{\"{u}}rgen B{\"{o}}rstler and
                  Nauman Bin Ali and
                  Oliver Kopp},
  title        = {Supporting the identification of prevalent quality issues in code
                  changes by analyzing reviewers' feedback},
  journal      = {Softw. Qual. J.},
  volume       = {33},
  number       = {2},
  pages        = {22},
  year         = {2025},
  url          = {https://doi.org/10.1007/s11219-025-09720-9},
  doi          = {10.1007/S11219-025-09720-9},
  timestamp    = {Mon, 12 May 2025 21:02:32 +0200},
  biburl       = {https://dblp.org/rec/journals/sqj/IftikharBAK25.bib},
  bibsource    = {dblp computer science bibliography, https://dblp.org}
}

It contains bibourl and bibsource

One could make these two fields required.

@article{withBibSource,
  journal      = {Softw. Qual. J.},
  bibsource = {2025}
}

@article{withoutBibSource,
  journal      = {Softw. Qual. J.},
}

With the existing consistency check, bibsource is reported as unknown. If the entry type article is modified to have this as optional field, it is reported as optional.

Task

• Modify org.jabref.logic.quality.consistency.BibliographyConsistencyCheck to use org.jabref.model.entry.BibEntryTypesManager instead of org.jabref.model.entry.types.BiblatexEntryTypeDefinitions#ALL

Hints

• Do test-driven development. Start atorg.jabref.logic.quality.consistency.BibliographyConsistencyCheckTest. Do not modify existing tests; add new ones.
• Look into org.jabref.model.entry.BibEntryTypesManagerTest for how to mock BibEntryTypesManager.
• Do not get confused with "library" and "database". User-facing we talk about "library", inside the code, we use "database", but mean "library".

[dcarpentiero]

/assign-me

[github-actions[bot]]

👋 Hey @dcarpentiero, thank you for your interest in this issue! 🎉

We're excited to have you on board. Start by exploring our Contributing guidelines, and don't forget to check out our workspace setup guidelines to get started smoothly.

For questions on JabRef functionality and the code base, you can consult the JabRef Guru or ask on our Gitter chat.

In case you encounter failing tests during development, please check our developer FAQs!

Having any questions or issues? Feel free to ask here on GitHub. Need help setting up your local workspace? Join the conversation on JabRef's Gitter chat. And don't hesitate to open a (draft) pull request early on to show the direction it is heading towards. This way, you will receive valuable feedback.

Happy coding! 🚀

[github-actions[bot]]

⏰ Assignment Reminder

Hi @dcarpentiero, this is a friendly reminder about your assignment to this issue.

[!WARNING] This issue will be automatically unassigned in 11 days if there's no activity.

Remember that you can ask the JabRef Guru or DeepWiki about anything regarding JabRef. Additionally, our contributing guide has hints on creating a pull request and a link to our Gitter chat.

How to keep your assignment

If you are working on it, you can prevent automatic unassignment by:

• Submitting a draft pull request with your progress within 11 days
• Asking for the 📌 Pinned label if you need more time

We appreciate your contribution and are here to help if needed!

[dcarpentiero]

/unassign-me

[github-actions[bot]]

📋 Assignment Update

Hi @dcarpentiero, you are no longer assigned to this issue.

Next steps

If you still want to work on this:

• Comment with /assign-me to request reassignment
• Ask a maintainer to assign you again
• If you're making progress, a maintainer can add the 📌 Pinned label to prevent future automatic unassignment

[Hrishi-Baskaran]

/assign-me

[github-actions[bot]]

👋 Hey @Hrishi-Baskaran, thank you for your interest in this issue! 🎉

We're excited to have you on board. Start by exploring our Contributing guidelines, and don't forget to check out our workspace setup guidelines to get started smoothly.

For questions on JabRef functionality and the code base, you can consult the JabRef Guru or ask on our Gitter chat.

In case you encounter failing tests during development, please check our developer FAQs!

Having any questions or issues? Feel free to ask here on GitHub. Need help setting up your local workspace? Join the conversation on JabRef's Gitter chat. And don't hesitate to open a (draft) pull request early on to show the direction it is heading towards. This way, you will receive valuable feedback.

Happy coding! 🚀

[Hrishi-Baskaran]

Hello @koppor , I'm reviewing both org.jabref.logic.quality.consistency.BibliographyConsistencyCheck.java and its corresponding test file. I have a question regarding the usage behind requiredFields which is declared in the method check: https://github.com/JabRef/jabref/blob/main/jablib/src/main/java/org/jabref/logic/quality/consistency/BibliographyConsistencyCheck.java#L105

The method javadoc says that it "does not check whether all required fields are present..." but the usage of the requiredFields variable seems to attempt this anyways. Even then, it doesn't seem to check it properly. It seems overly strict, requiring that all subfields of an OrFields should be present for an entry to be considered consistent. It does this by flattening the OrFields on line 143, and then filtering a filter operation using requiredFields on line 80.

From my understanding, at least one (not all) subfield(s) of an OrFields type should be present for that field's requirement to be satisfied.

I'm asking this question to confirm and improve my understanding of the class and how I can modify it for this PR

[github-actions[bot]]

⏰ Assignment Reminder

Hi @Hrishi-Baskaran, this is a friendly reminder about your assignment to this issue.

[!WARNING] This issue will be automatically unassigned in 11 days if there's no activity.

Remember that you can ask the JabRef Guru or DeepWiki about anything regarding JabRef. Additionally, our contributing guide has hints on creating a pull request and a link to our Gitter chat.

How to keep your assignment

If you are working on it, you can prevent automatic unassignment by:

• Submitting a draft pull request with your progress within 11 days
• Asking for the 📌 Pinned label if you need more time

We appreciate your contribution and are here to help if needed!

[koppor]

@Hrishi-Baskaran Seems your explanation is right. You can try to fix it 👍

[Hrishi-Baskaran]

@koppor Okay, it seems like a large number of tests need to be refactored because they rely on the old incorrect, required field logic. I think it would be best if I keep the required check how it is for this issue. Then open a separate issue where I modify the required field check

[koppor]

@koppor Okay, it seems like a large number of tests need to be refactored because they rely on the old incorrect, required field logic.

"Large number" in the sense of 1000 or more?

Please point to them, without any reference, I cannot judge.

At the last try of this PR, the contributor modified tests only to follow the new interface - https://github.com/JabRef/jabref/pull/13799/files#diff-cb76678982120b769f5f34382d893e82ab46e4805abde542736d5ec26e891c92

[Hrishi-Baskaran]

Okay so it's actually around 10 or so unit tests that were failing. Here's an example of one that was failing:

https://github.com/JabRef/jabref/blob/main/jablib/src/test/java/org/jabref/logic/quality/consistency/BibliographyConsistencyCheckTest.java#L100

The assertion expects the InProceeding with citation key "fifth" to be returned in the resultMap. However, it is not returned by the actual check.

The fifth entry's fields are a subset of the intersection of that of all InProcedding entries (i.e. the fifth entries fields are all inside of fieldsInAllEntries defined in the check function). Therefore, after removing the required field check in the check function, this fifth entry is not returned

The only reason I could think the test maker made the expected resultMap include the fifth entry would be because the fifth field lacks required fields. That implies that the required field check is intentional. I didn't want to change all test cases that relies on the required field check without confirming that it truly is unintentional. Either way, it seems like this is a entirely seperate issue to what is required of this pull request (support of custom entry types), so it should be put on another issue.

I'd say that we do one of two things depending on whether its intentional for the check function to also check if an entry has its required fields

1. The intended behavior of the check function is to also check for required fields

• Open a new issue to modify the check function to correctly handle the case of required OrFields

2. The intended behavior of the check function is to not check for required fields, only inconsisently set ones

• Open a new issue to modify the check function to remove the required fields check from the check function and modify existing test cases accordingly.

I would also like to point out that in the PR you showed of the last attempt to solve this issue, the user kept the required fields check as seen in this line https://github.com/JabRef/jabref/pull/13799/files#diff-72370ff3854216f72af92bd9037b16ec26257efb4fc057a596ab1d5b79427bacR81#L81 becuse of this, they didn't have to change any of the unit tests like the one I discussed above.