Preserve casing of field names for customize entry types

[koppor]

Follow-up to #9977, refs #9840.

This PR especially (tries) to adhere that Field is constant and that the ViewModel is the thing collecting data and at the end converts it to a "real" data object.

Result of a coding session started with @calixtus and @Siedlerchr.

---

@Comment{jabref-entrytype: person: req[GoogleScholar;ORCID;name] opt[]}

@Person{,
  googlescholar = {test1},
  name          = {test3},
  orcid         = {test2},
}

---

Mandatory checks

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• 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.

[Siedlerchr]

BibtexDatabaseWriterTest > writeCustomizedTypesInAlphabeticalOrder() FAILED

[Siedlerchr]

I guess this will break many tests! Rather add a new method

[koppor]

Introduced org.jabref.gui.importer.BibEntryTypePrefsAndFileViewModel to really fix that comment.

[Siedlerchr]

I think there was a reason to pass a modifiable list

[koppor]

I double checked the code - no modification of the list inside. I added a JavaDoc comment.

[Siedlerchr]

The problem you know have is that the tests don't distinguish between custom field names and normal field names if they have the same name. This is hella complex now...

[koppor]

The problem you know have is that the tests don't distinguish between custom field names and normal field names if they have the same name. This is hella complex now...

Please unzip. 😅 MetaDataParsing: Yesterday, we opted to use org.jabref.model.entry.field.FieldFactory#parseField(T, java.lang.String), which never produces custom fields (UnknownField) in case the name is known. Thus, there cannot be any "custom field name" with a name available in standard field names. - The only issue is at the UI when generating the field. This place also uses the parseField (via org.jabref.gui.util.FieldsUtil#FIELD_STRING_CONVERTER).

[Siedlerchr]

Please take a look at the failng tests :-P

[Siedlerchr]

Only problem I now see is migration of existing custom entry types/fields.
that will break existing bib files

[koppor]

Only problem I now see is migration of existing custom entry types/fields.
that will break existing bib files

Why? When parsing the bib file, the casing is stored in JabRef. That casing is written out again. Thus, the bib file are kept.as is..IMHO also covered by tests.

What does break is the UI: The first letter will be lower case.

[Siedlerchr]

Yeah, seems fine but after we resave it in the UI the casing is changed?

[koppor]

Yeah, seems fine but after we resave it in the UI the casing is changed?

The UI displays the casing found in the bib file..

User modifies casing: bib modified

User does not modify casing: bib not modified

IMHO as exected.

[Siedlerchr]

no risk no fun!