Enhance customization of entry types

[koppor]

As user, I want to create a new entry type. For example, a new entry type "Person" with "name" and "googlescholar" as fields. JabRef offers advanced field handling for names, URLs, and more. This is implemented using org.jabref.model.entry.field.FieldProperty. The current dialog enables only the addition and deletion of fields. Not assigning field properties or changing the name.

Thus, TODOs:

• Enable setting zero ore more org.jabref.model.entry.field.FieldPropertys. Should be done in a combo-box allowing multiple selections.
• Enable update of name: I cannot fix typos in the name -- it should be possible to double click the name and then change the value:
• Optional: Enable casing: I tried to add "GoogleScholar", but I could not type the capital "s". I think, users should be allowed to use arbitrary casing?

More information

• User documentation of the feature available at https://docs.jabref.org/setup/customentrytypes.
• Markdown for the documentation (to modify) at https://github.com/JabRef/user-documentation/blob/main/en/setup/customentrytypes.md
• Fields can also have no property. That means, it is a plain text, single line text field. See also

  jabref/src/main/java/org/jabref/model/entry/field/InternalField.java

  Line 57 in 6269698

  InternalField(String name) {

[eric052199]

Hey team, can i work on this issue?

[github-actions]

As a general advice for newcomers: check out Contributing for a start. Also, guidelines for setting up a local workspace is worth having a look at.

Feel free to ask here at GitHub, if you have any issue related questions. If you have questions about how to setup your workspace use JabRef's Gitter chat. Try to open a (draft) pull-request early on, so that people can see you are working on the issue and so that they can see the direction the pull request is heading towards. This way, you will likely receive valuable feedback.

[eric052199]

Hi, can you please explain more about the first todo? Not sure about what setting zero or more FieldProperty means.

[koppor]

@eric052199 For me, it is not clear, what is unclear to you ^^.

I try to write a few text on "Enable setting zero ore more org.jabref.model.entry.field.FieldPropertys." Please ask which item should I refine or if you need additional information.

1. The class /src/main/java/org/jabref/model/entry/field/FieldProperty.java#L3 models properties of a field
2. An EntryType specifies which fields are contained
3. Custom Entry types are stored in /src/main/java/org/jabref/model/entry/types/UnknownEntryType.java#L8
4. Custom Fields are stored in org.jabref.model.entry.field.UnknownField
5. From the UI, a new Custom Entry Type is generated at org.jabref.gui.preferences.customentrytypes.CustomEntryTypesTabViewModel#addNewCustomEntryType
6. org.jabref.gui.preferences.customentrytypes.CustomEntryTypesTabViewModel#addNewField is used to add a new field to the customized entry type
7. There, org.jabref.gui.preferences.customentrytypes.FieldViewModel class is used to put a single FieldProperty. The issue is to be able to add more than one property
8. JabRef saves the customized entry types into the .bib file:\

   @Comment{jabref-entrytype: person: req[Name] opt[Googlescholar;Orcid]}

9. an example person looks as follows:\

   @Person{demo,
     name          = {Oliver Kopp},
     googlescholar = {https://scholar.google.de/citations?user=nB2GungAAAAJ&hl=de&oi=ao},
     orcid         = {https://orcid.org/0000-0001-6962-4290},
   }

10. Proposal for the new format: Use | to separate field names with the list field properties:

• @Comment{jabref-entrytype-v2: person: req[Name|PERSON_NAME] opt[Googlescholar|EXTERNAL;Orcid|EXTERNAL]}
• @Comment{jabref-entrytype-v2: customizedtype: req[title;author;date] opt[year;month;publisher]}
• Note that is not necessary to provide properties to already known field names. It is not possible to overwrite field properties (currently). Reason: Parsing logic at /src/main/java/org/jabref/model/entry/field/FieldFactory.java#L76. You can think of changing this in your implementation. But take this as optional.
• New field properties can be added by passing them at /src/main/java/org/jabref/model/entry/field/FieldFactory.java#L90

   .orElse(new UnknownField(fieldName));

• Note that I added -v2, because the new format is NOT backwards-compatible with the old one and thus JabRef users might loose data if they switch versions back and forth.
• Note that there might be no field properties given. See discussion at No user info about changing bib-format in 4.0 #3251.
• The proposal is NOT backwards-compatible. We can also come up with a completely new format. Nested JSON. Then, the string after jabref-entrytype-v2: needs to be forwarded to a JSON parser.

Hints:

1. IDE hint: By holding Ctrl and then click with the mouse on an identifier, you can navigate to the usage of a class, method, etc.
2. IDE hint: By holdingCtrl+Shift+F, you can search all text occurrences. Helpful to find some code.
3. Please try to understand the current UI
4. Add a sketch of the new UI - maybe this helps to understand the issue more
5. Define the new data format for writing jabref-entrytype
6. Add test cases for the new data format. The tests should go into org.jabref.logic.exporter.MetaDataSerializerTest.
7. A new test class for org.jabref.logic.importer.util.MetaDataParser. Needs to be created. This can be done with Ctrl+Shift+T and then Enter. parseCustomEntryType should be tested.
8. You can also work on org.jabref.model.entry.field.FieldFactoryTest, because org.jabref.model.entry.field.FieldFactory is called in MetaDataParser.
9. Other tests are in org.jabref.model.entry.BibEntryTypesManagerTest
10. More tests should go into org.jabref.logic.exporter.BibtexDatabaseWriterTest
11. Please do test-driven development. Thus, please add test cases and then use the debugger to step into the methods. Then change the methods. With that, you save development time. If you use the GUI to test your implementation, you will be slow in developing.

[ThiloteE]

"BibTEX does not distinguish between normal and capital letters in entry and field names"

- tamethebeast p. 20

[koppor]

The entry field casing is the least important wish of the issue. I have removed the requirement to put the focus on the important code changes.

Background information: The field capitalization refs JabRef/blog.jabref.org#47 and #8676

[koppor]

After this is fixed, please check if #5857 is also fixed.

[koppor]

@eric052199 I saw activity on the minor TODOs of this PR. May I ask if you work on the big TODO, too?

[koppor]

@DinjerChang @eric052199 #9993 is now merged.

Now, it should be even more easy to work to fix this issue. Please remind my hints at #9840 (comment). Please reach out if something is unclear.

[DinjerChang]

@koppor Thank you very much! I'll hop on to it after finals.

[Xavieryyu]

Hi. Can I continue working on this issue?

[ThiloteE]

Apparently, yes. Nice catch for noticing nobody was assigned ;-)

[Siedlerchr]

This issue is free to take again! There is still only one thing missing

[enesbkoca]

Hey. I'd like to work on this issue, can you assign me to it? Thanks :)

[koppor]

@enesbkoca Nice! Looking forward!

[enesbkoca]

Hi, I've looked into this issue, and it seems to be more complicated than I initially thought and due to time constraints I'm afraid I will not be able to implement this issue. For this reason I'd like to be unassigned, my apologies.

[aqurilla]

Hi! I’d like to take up this issue

[ThiloteE]

Hi @aqurilla, nice to see you again :-)

[aqurilla]

@ThiloteE thankyou, happy to be back! :D

[ThiloteE]

This change will add to the proliferation of undocumented entry types that will probably be shared with colleagues and in the wild. Maybe there should be some kind of documentation or "info" that points to the biblatex issue tracker for people that want to make their entry type "official".

[koppor]

Note that "nonWrappable" fields is the current configuration for multiline fields. With "wrappable" we meant that JabRef can automatically introduce linebreaks whenever it thinks, it is good.

[Siedlerchr]

Originally there existed only the "wrappable fields" options, meant for saving the fields with linebreaks in between or not. This is important as otherwise, for example, a line break inside the content of the URL or DOI field would break the link in LaTeX documents when rendering.
Then it was misused as an easy way for users to be able to also configure it in the UI (entry editor).

However, these two features should be decoupled now!

[koppor]

Originally there existed only the "wrappable fields" options, meant for saving the fields with linebreaks in between or not. This is important as otherwise, for example, a line break inside the content of the URL or DOI field would break the link in LaTeX documents when rendering. Then it was misused as an easy way for users to be able to also configure it in the UI (entry editor).

However, these two features should be decoupled now!

No - see #12032.