(Sub)Subgroups by keyword in Groups pane do not capture nested keyword entries

[bemilton]

JabRef version:

JabRef 5.3--2021-01-10--0a971fd
Linux 5.9.13
Java 15.0.1 
JavaFX 15.0.1+1

$ java -version
openjdk version "14.0.2" 2020-07-14
OpenJDK Runtime Environment (build 14.0.2+12)
OpenJDK 64-bit Server VM (build 14.0.2+12, mixed mode)

This bug report relates to my Question raised here, which turns out to be a bug.

• [ * ] Mandatory: I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

Steps to reproduce the behaviour:

1. Using your own library open JabRef and click the '+' for a new group in the Group pane.
2. Give the new group a name, e.g. "By keyword" will do and select Independent for Hierarchical context
3. Select Specified keywords under Collect by and click Generate groups from keywords in the following field
4. type keywords in Field to group by and specify semi-colon ; twice in each field for Delimiter(s)
5. Click OK

Note: In step (4) I specified ; twice. I do this twice because I have noticed more consistent behaviour in the UI and groups when typing the delimiter twice rather than leaving one field blank. However, this is not the focus of this bug report. Next, I use semi-colon, but you should use whatever your bib(la)tex source delimiter is.

When you do this you'll have a group under the Groups pane titled By keyword. Subgroups will contain entries collected by keyword in the keywords = {...}, variable of the library bib(la)tex source.

6. Now click any entry in your library. Using the entry editor (bottom pane or ctrl+E if it is not visible) select biblatex source and if you do not have a keywords variable present then add the following to the entry's source:

keywords = {TEST_GRP>TEST_KW; TEST_GRP_B;},

(Or, if keywords exists just append my string within the braces to your keywords if already present)

7. Save your library (top right save icon). Then go to File and Quit
8. Re-run JabRef, and check the library entry you used in (6) still contains the string between the braces (to ensure the save operation in (7) was successful - if it didn't properly save, go back to step (6)).
9. Using the Groups pane scroll through the By keyword collection and look for subgroup TEST_GRP and TEST_GRP_B.
10. Notice how TEST_GRP has a sub-subgroup TEST_KW with zero entries, but TEST_GRP_B has exactly 1.

BUG: The expected result should be TEST_KW and TEST_GRP_B contain exactly 1 entry which is the library entry used in step (6). The bug is that nested keywords are not capturing the entry and the sub/subgroup integer value does not increment. Non-nested keywords however do work correctly.

I have run JabRef with jabref --console and jabref --debug to give stdout, but there is no useful output to attach. Perhaps you can show me where to make changes to the JVM config to write debug to a file?

EDIT:

• Presumably this was working at some point ?
• Why isn't the use of > and | as a nesting operator for the Groups pane via the keywords field included in the docs?

[k3KAW8Pnf7mkmdSMPHz27]

@bjhamilton I'll just briefly answer parts of your PS. I want two things to be clear,

1. I am a volunteer contributor to JabRef. This is my opinion and how I view things,
2. I am intentionally brief and it is not meant to be terse. However, I obviously need to work on my communication skills, and I am trying to be brief to avoid creating more confusion 😝 Please try to interpret everything as its most positive, it is how it is intended.

it was a valid action at the time given Jabref > New Issue > Question was an available option

It was an available option, but the text

---

Please use the GitHub issue tracker only for bug reports and suggestions for improvements. Feature requests, questions and general feedback is now handled at http://discourse.jabref.org. Thanks!

---

were shown as a comment in the text field were you wrote your question, I'd guess this is what tobiasdiez refers to. The original options were created 2 years ago, and I'd guess that these "links" that my commit added were not possible at that time.

When you said you had some work to do why'd you wait for me to raise this given you'd already tested it

When a user creates an issue for a bug, I know that someone is using that feature and that they define what is required for the issue to be fixed. This is important because with a very high likelihood, if there is a bug, it means that both the person fixing the issue and the persons reviewing the changes have not used that feature. You are the one setting the scope for what will be solved.

Perhaps I should have created this issue myself, but I did not completely understand your original question, and I still don't. If you believe this will solve it, it is imo fair enough. If I had created this issue, it would have forced me to spend time restricting the scope of this issue based on trying to understand the intended functionality from the source code. This is quite time inefficient, it would likely have lead to a different scope, and it is time that I might now spend fixing the issue instead 😜

Remember, everyone here is a volunteer and is doing this on their spare time. I am unemployed and I have issue finding enough time to deal with JabRef and its community. In my opinion, given that the JabRef core has day jobs, they must be demi-gods creating spare-time from empty space.

Lastly. I am not going to write anything more regarding anything not strictly related to the technical part of this issue. I don't think my involvement has been positive. My apologies to everyone involved.

[tobiasdiez]

I think this is bound to happen if communication only takes place only and one doesn't know each other already in real life, especially combined with expectations and frustrations on both sides (user: "This is not working as I want it to be - shit - Please fix it asap!", developer: "God damn, another broken thing. I wanted to work on something else actually. - Please give at least enough information to reproduce it."). I hope everyone is kind of happy again and we can move on to fixing the actual issue.

The feature works in principle (I use it daily), so I guess it it's specific to this setup / example. First of all, the delimiters should be ; first and then > second, otherwise JabRef cannot distinguish between linear and hierarchical levels.
Improvement: Don't allow the user to put the same delimiter in the edit dialog.
Improvement: Explain this feature in the documentation.

Secondly, I think there is a space missing. Could you try with TEST_GRP > TEST_KW please?
Possible bug: This should also work without spaces around >.

[bemilton]

Lastly. I am not going to write anything more regarding anything not strictly related to the technical part of this issue. I don't think my involvement has been positive.

Don't leave on the basis you believe you have not been constructive. I don't take this view. I was being playful and didn't intend to cause a bad impression. My apologies.

In my opinion, given that the JabRef core has day jobs, they must be demi-gods creating spare-time from empty space.

100%! Great software.

the delimiters should be ; first and then > second, otherwise JabRef cannot distinguish between linear and hierarchical levels.

That was the source of the problem. Many thanks for resolving this for me. I'm pleased that two improvements came out of this at least.

[tobiasdiez]

Glad it worked for you. May I ask you to revise the documentation accordingly so that other users have a smoother path using that feature: https://github.com/JabRef/user-documentation/blob/master/en/finding-sorting-and-cleaning-entries/groups.md

[bemilton]

Sure.