An empty entry can still be added without warning message (and lead to an error when compiling)

[mlep]

JabRef version

Latest development branch build (please note build date below)

Operating system

GNU / Linux

Details on version and operating system

JabRef 5.6--2022-04-04--dbf921e Linux 4.19.0-20-amd64 amd64 Java 17.0.2 JavaFX 18+12

Checked with the latest development build

• [X] I made a backup of my libraries before testing the latest development version.
• [X] I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

1. Open a library
2. Add an entry (by clicking on the + button, for example)
3. Save the library
4. Close the library

No warning message is displayed (unlike stated in issue #8096), especially not the message of the PR #8218. And so, the issue #8096 is still present: biber generates an error ([8337] Utils.pm:411> ERROR - BibTeX subsystem: /tmp/biber_tmp_Qtbu/a9e03cb3043b9e2c02591da84105bb68_26801.utf8, line 36978, syntax error: found ",", expected one of: number, name (entry type, key, field, or macro name), end of entry ("}" or ")") or quoted string ({...} or "..."))

My analysis:

1. the current definition of an empty entry is probably too strict. For me, by default, an empty entry is

@Article{,
  creationdate = {2022-04-05T10:41:54},
  owner        = {mlep},
}

So, not really an empty entry. But, since an empty entry key is enough to lead to a biber error, I suggest an empty key should be enough to raise the warning message.

2. Because you can compile your file after saving (i.e. while keeping your library opened), the biber error is generated before the warning message has a chance to be displayed. Hence, the warning message should be displayed on saving (i.e. not on closing).

3. The feature "Generate keys before saving (for entries without a key)" in Options -> Preferences -> Citation key generator is of no help because no key are generated for such an "almost empty entry".

Appendix

...

Log File

Paste an excerpt of your log file here

[mlep]

@ruoyu-qian: You may want to enhance your previous contribution to JabRef. Cheers.

[ThiloteE]

3. The feature "Generate keys before saving (for entries without a key)" in Options -> Preferences -> Citation key generator is of no help because no key are generated for such an "almost empty entry".

Wait, this preference seems broken then?

Edit: It is not broken. On my machine it works. It creates a citation key, when clicking on save, but only if the fields present in the entry are detected by my citationkey pattern.

Here my pattern: [shortauthor:([authEtAl:([organization:([institution])])])][date:([year:([urldate])])][shorttitleINI:lower]. You will notice, it does not detect the fields creationdate and owner,

hence my pattern also, just as you, does NOT create a citationkey for

@Article{,
  creationdate = {2022-04-05T10:41:54},
  owner        = {mlep},
}

[mlep]

@ThiloteE Not really: my key pattern is [auth][shortyear]. Since my "almost empty" entry does not have an author or a year, I cannot really blame this feature. :wink:

[ThiloteE]

Put devcall label, because there is the idea to get rid of the whole dialogue and delete empty entries silently upon closing JabRef.

[koppor]

We need to refine the functionality Generate keys before saving (for entries without a key)".

Actions needed

• [x] ~Set the default to true in the preferences~ Edit: Let default remain at false
  • Because:
    1. Old time users of JabRef may intentionally have some "empty entries".
    2. New users of JabRef may wonder why JabRef automatically changes their database.
    3. Large Databases with many old empty entries may trigger many diffs and the duplicate merge dialogue, if these databases are shared with other users
• [ ] In case a new empty key is "generated", there should be a random number generated.
  • Proposal: FIXME (without any addition), reasoning: on duplicate key: There is an error dialog showing duplicate key. This "annoys" the user and this is an important thing to take care as user.
    • Alternative gen-1, gen-2, gen-3, ...
    • Alternative gen- plus the Java object hash written as hex string.
• [x] After implementation, remove "check for empty entries" dialog (on save)
• [ ] Add "Integrity check" for empty BibTeX key
  
  Currently, there are no errors reported

Discussion

• Alternative solution: Detect if an entry has autogenerated fields only. Then, this counts as "empty entry" in the functionality at save of "empty entries". This required more effort, because there needs to be consistency between autogenerated fields and this functionality. Hard to maintain in the long run, because of code cross-references.

Positive Consequences:

• Makes the code introduced at https://github.com/JabRef/jabref/pull/8218 obsolete. That code needs to be removed when working on this PR.
• Makes PR https://github.com/JabRef/jabref/pull/8767 obsolete

[koppor]

The challenge to work on this issue is to craft test cases.

[koppor]

We went for the simple solution: Do not write empty entries to the .bib file. When closing and opening JabRef again, these "empty" entries are gone.

TODO-tracking needs to be done by groups or other measures of JabRef.