Unexpected interaction of keyword and static groups

[sauliusg]

JabRef version 5.0-dev (commit db96f88 master) on Ubuntu-16.04 x86_64

• [x ] I have tested the latest development version from * master db96f88 Fix problem with search and switching between libraries (#5326) from https://github.com/JabRef/jabref.git and the problem persists

The GUI allows to add a static group (or another manually created group) to an automatically create(d) keyword group. However, when such new group is created as a subgroup of the root keyword group ("kwds" in my example), it is not displayed in the GUI, although it is registered in the program (the second group with the same name can not be created), and is written into the bibliography file. The only way to access or get rid of such group seems to be manual editing of the bibtex file.

If, on the other hand, the new group is manually created as a subgroup of a sub-keyword, it is displayed in the GUI, but is not saved into the output file.

Steps to reproduce the behavior:

1. Copy the example bibtex database to a new file (both files are in test-keyword-groups.zip):
   cp test-keyword-groups-saved.bib test-keyword-groups.bib
2. Run JabRef on the copy of the file:
   build/image/bin/JabRefMain test-keyword-groups.bib &
3. Create an "Automatically create groups" subgroup on all entries, call it "kwds":
   
4. Try to add a "sub-kwds" group by right clicking on the "kwds" group and then immediately "OK". The group is created but not shown on the GUI:
   
5. Now try to create a group with the same name, "sub-kwds", as as subgroup of "All entries" (right click on "All entries", select "Add subgroup", enter "sub-kwds" as "Name", click "OK"). An error message "There exists already a group with the same name" appears. The "sub-kwds" group, however, is not shown, even after collapsing and expanding the "kwds" groups:
   
6. Add a sub-group of some keyword: right-click on "languages", select "Add subgroup", name it "sub-languages", click "OK". A new sub-group appears on the list:
   
7. Click the "Save library" icon to save the bibtex file; exit the JabRef.

The resulting "test-keyword-groups.bib" file has the following groups:

@Comment{jabref-meta: grouping:
0 AllEntriesGroup:;
1 AutomaticKeywordGroup:kwds\;0\;keywords\;,\;>\;1\;0xffffffff\;\;\;;
2 StaticGroup:sub-kwds\;0\;1\;0xffffffff\;\;\;;
}

Loading this file again into JabRef obviously will miss the "sub-languages" group (which was shown on the GUI!), but will retain the hidden "sub-kwds" group; this group is not shown on the GUI but one can not create such group once more (thus it is registered in the group list). A workaround to "unhide" this group is to edit the "test-keyword-groups.bib" with a text editor and change 2 StaticGroup:sub-kwds to 1 StaticGroup:sub-kwds, for example.

Both BibTeX files are attached in a ZIP archive.
test-keyword-groups.zip

[tobiasdiez]

All subgroups (regardless of there level) of an automatic group should be read-only to every action (i.e drag&drop, edit and adding subgroups should not be possible).

[sauliusg]

Thanks for the instant reply! Making auto-groups r/o seems like a good solution.

[sauliusg]

On a second thought, keyword groups read-only could remove useful functionality.
Another idea would be to use the same Java code to handle static groups and keyword groups. The advantages would be:

• more functions implemented in less code :);

• both automatic groups and static groups would behave in a similar way, reducing confusion and learning curve height;

• Since keywords now can be hierarchical with the same sub-keyword attached to different main keywords (like in "Astma > Treatment" and "Diabetes > Treatment", as per Feature: Hierarchical Keywords #628 and Towards hierarchical keywords #1950), the same functionality would be possible for the static groups!

I apologise for resurrecting issues #3115 and #1873, but the ability to have subgroups with the same name in various parts in the group tree seems essential (all competing bibliography managers can do it seamlessly, and people are used to that). The naming scheme used in hierarchical keywords seems to resolve the name uniqueness issue in the Java code.

[github-actions]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!