Hey team, can i work on this issue?

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.

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

@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.

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

- tamethebeast p. 20

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

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

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

@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.

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

@koppor I currently used a checkComboBox from org.controlsfx.control.CheckComboBox next to the field Combox. I added all the FieldsProperty by fieldPropertyCheckComboBox.getItems().addAll(FieldProperty.values()); in CustomEntryTypesTab#initialize(). I'm wondering the timing that allow user to set the field properties. Following are my thoughts right now:

1. After user type in the field name but before pressing the add button, enable the CheckComboBox to allow user to set field properties. Once they choose the properties, and they could press add button.
2. After user type in the field name and add it to the field column, and then, when they select the field, enable CheckComboBox to allow user to set field properties. There will be a new "plus sign" button next to the CheckComboBox to handle the logic

Not sure if I'm on the right track and would love to discuss more

Thank you for continuing working on this.

The dropdown with the selection allements is good.

I would suggest to modify the field labels of the add buttons to really show the action taken "Add" or "Modify".

The property can be empty, then you can show ("default") in gray (if that is possible in JavaFX). Otherwise, leave the box empty.

In case the user modifies the field name on the left and the field does not exist, the button label "Modify" should change ot "Add". In case the user modifies the field name to an existing field again, the button should change to "Modify" again.

You can also add a button with the small circle" next to the "Modify" button. If pressed, it will reset the field properties (and the casing of the field name) to the original value. -- In other words, a field-local version of the "Reset to default" button.

Hi Team

This is my first time in contributing to open source I have tried to do some coding on this issue and was able to attach field properties for new fields as below.

is It possible to be assigned to work on this ?
I have passed the checkComboBox as a reference to obtain the values selected from it.

public void addNewField(CheckComboBox addFieldValue) { Field field = newFieldToAdd.getValue(); boolean fieldExists = displayNameExists(field.getDisplayName()); if (fieldExists) { List<FieldProperty> list = addFieldValue.getCheckModel().getCheckedItems(); field.getProperties().removeAll(field.getProperties()); for (int i = 0; i < list.size(); i++) { field.getProperties().add(list.get(i)); } }

@shihar94 are you also a member of @DinjerChang and @eric052199's team? I appreciate your effort, but have you seen they are already working on it?

@ThiloteE
Thank you for the immediate reply. I wasn't sure if they had completed it. Will try to move to another issue.

Thank you very much. In most cases, we try to keep issues and projects for students separate, so as to not interfere with any grading method that is not compatible with outside interference.

@koppor

• At Step 10, you mentioned:
  Note that is not necessary to provide properties to already known field names. It is not possible to overwrite field properties (currently).
  I'm wondering so when adding new field or modifying field properties, only the an UnknownField being entered or selected could have access to the the field properties drop down menu(CheckComboBox)?

• Passing field properties in FieldFactory
  .orElse(new UnknownField(fieldName)); this cause a lot of issue when I modified it, I stuck on it quite few days.
  My solution right now is simply update the field properties in the FieldViewModel.java#toField() with field.getProperties().addAll(fieldProperties) after Field field = FieldFactory.parseField(displayName.getValue()), where Set<FieldProperty>fieldProperties will be assigned at the constructor

• I'm wondering why we already construct a Field at CustomEntryTypesTabViewModel#addNewField and passing it to the FieldViewModel, but we reconstruct the Field again with FieldViewModel#toField(). I'm thinking can we simply assign the the passed in Field to a final variable

Correct me if I'm wrong :)

• At Step 10, you mentioned:
  Note that is not necessary to provide properties to already known field names. It is not possible to overwrite field properties (currently).
  I'm wondering so when adding new field or modifying field properties, only the an UnknownField being entered or selected could have access to the the field properties drop down menu(CheckComboBox)?

I don't understand "could have access". - These properties should be rendered in the UI but not modifiable for standard fields. For Unknown fields, they should both be rendered and modifable.

• Passing field properties in FieldFactory
  .orElse(new UnknownField(fieldName)); this cause a lot of issue when I modified it, I stuck on it quite few days.
  My solution right now is simply update the field properties in the FieldViewModel.java#toField() with field.getProperties().addAll(fieldProperties) after Field field = FieldFactory.parseField(displayName.getValue()), where Set<FieldProperty>fieldProperties will be assigned at the constructor

Reads good.

• I'm wondering why we already construct a Field at CustomEntryTypesTabViewModel#addNewField and passing it to the FieldViewModel, but we reconstruct the Field again with FieldViewModel#toField(). I'm thinking can we simply assign the the passed in Field to a final variable

Need to think longer. Can only write the rough idea: The FieldViewModel is a "factory" for the final model. The idea is that an object goes into the ViewModel, which extracts data from that. Then it is modified. Then, a new object is created from that data. Reason: the incoming object might be a "constant" object. All ViewModels should be implemented the same way.

@calixtus Maybe you have something to add?

@koppor Sorry for the unclear explanation of Section 1. What I've done right now,

• Case 1: there is a field Abstract, which is a StandardField, on the table right now. When I clicked on it, the buttonAdd/Modify is disabled.

• Case2: when a user select a StandardField from the field type ComboBox or type in a name of StandardField directly, let's say CitationKey, which is not on the field table yet, the system will check if the input field is not a StandardField at the CustomEntryTypesTabViewModel#addNewField by if (!fieldsForAdding.stream().anyMatch(standardField -> standardField.getDisplayName().equalsIgnoreCase(field.getDisplayName()))){ field.getProperties().addAll(fieldProperties);}.
  If False, we don't do anything. If True, means that it's an ** UnknownField** then we add the field properties based on what user selected. In this case, the button Add will be enabled to allow user to add the field. However, it won't set any field properties even "DATE" and "DOI" are chosen

• Case 3: When I clicked on a UnknownField, the button Modify is enable

Then let's remove this from good first issues.

Please leave the good first issues label on.
As I said, good first issues does not mean that this is a newbie issue, but a good first issue for java programmers to start in the jabref code.

Thanks. I'm not very experienced with javaFX, I have experience with java spring for backend, but I will dedicate myself to solving this problem.

Hey guys, I'm having a lot of difficulty completing this task, I'm going to unassign me here and try to find another task. Sorry

@IsaacDMz Okay, if you need some inspiration: You can browse through our project lists:
https://github.com/orgs/JabRef/projects
We tried to categorize the issues

Can i work on the first todo of this issue?

@nio2004 sure. I will assign you.

Hi. Can I continue working on this issue?

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

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

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

@enesbkoca Nice! Looking forward!

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.

Hi! I’d like to take up this issue

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

@ThiloteE thankyou, happy to be back! :D