I tried out JabRef 3.8.1, but it was not satisfactory because it still has not resolved the problem of subgrounps having the same name. For this and some other problems with the new version I had to retreat to back to 2.11b4. However, treying out the new version damaged the old one.
I have seven databases. Two of them display groups, but the other five group hierarchies are now missing. I assume the damage was to file in the jabref-master directory, but I don’t know which file to recover from backup.
Newer version of JabRef move some information in the @comment{jabref-meta:groups} comment at the end of the bib-file to the groups field of the entries. So you need to restore the comment part at the end of your bib files in order to make them work with older versions.
Sorry for the inconvenience caused by the bug with same group names.
This is the same as the .bib file used by JabRef 3.8.1 I have no “@comment{jabref-meta: groups}” line in these database files. Without groups I’m forced to use JabRef 3.8.1, even though no one has been able to figure out how to distinguish multiple uses of the same group name. For example, a history database has a hierarchy of geographic locations, each of which has a subgroup “feudal”. When the “feudal” group is selected, there’s an enormous number of hits, most of which are not relevant to the desired selection. I had suggested that instead of a simple group name, the hierarchy were used (for example, groups={France;feudal} and groups={Iran;feudal}, there would be no problem, but apparently this is not so simple to implement.
Sorry, it was the groupstree comment. An ExplicitGroup contained a list of BibTeX keys of the referenced entries, newer versions don’t have such a list.
Yes, I really would like to fix the bug using the hierarchical keywords as you proposed, but this is not easy to implement. Right now, each group does not know about its position in the tree and thus right now it is not possible to make the groups field dependent on the position in the group tree (moreover, if you move a group to another location in the tree, then all its entries have to be updated properly and similar sync issues have to be considered). Thus such a change is not a simple one-liner but a bigger project. You can follow the progress here https://github.com/JabRef/jabref/issues/1495
However, my copy of version 3.8.1 is causing distress. At some point today all lines at the end of one of my bib database files were truncated and replaced by these three lines.
Now the groups interface for this database has “All entries” at top and nothing else. You seem to have suggested that “some” information in the groupstree comment would be moved to the “groups field of the entries”. Is the field in the bibtex file “groups = {},” ? If so, I see that the entires in the damaged database does have this field. I could go back to a backup to restore the lost material at the end of the damaged database, but I’d really like to know what happened because there’s a chance such a measure might miss a new modification to the groups list.
Another problem, perhaps related to this one, I can’t get rid of fossil search terms for some databases. The first database has a null search term, but second database does not forget an old search term. As the result I don’t see all entires until I click Clear. The fourth database has null term, but the fifth and seventh have fossil search terms. The eighth has null term. Clearing thee search term does not remove them permanently, for whenever I return to the database, they show up again. It seems this problem showed up in the course of today the same time as the groups problem.
If you have a database that uses groups with the same name, I suggest the following:
Restore the groupstree comment from your backup and remove all the groups = … fields
Open the restored bib file with an older JabRef
Let me give you some insight into how this bug arises (and what changed in newer Jabref versions regarding the groupstree comment and groups field):
Previously, each group stored the entries that belonged to it. This kind of information was saved in the groupstree comment in the form ExpliciteGroup: name of group and other settings; a list of BibTeX keys to the assigned entries. This lead to problems when the key changed, sharing entries including their group membership and in similar situations.
Thus we changed the format how entries are linked to the group. In newer versions, every entry itself stores the name of the group to which it belongs in form of the groups field. This solution works really well (since groups are more stable and can be changed only in certain places). So in the newer versions the groupstree only stores the name of the group and a few settings, but no longer the BibTeX keys of the referenced entries.
Everytime you open a database in the old format in a newer JabRef, the groups information is converted to the new form.
Hope this explains the changes a bit.
Regarding your problems with the search, can you please open a new issue on github, where you describe the issue in more detail and in the best case append a bib file so that we can reproduce the problem.
Well, when I restarted JabRef, the fossil search terms disappeared. So no bug in that department.
I followed your suggestion and transferred a backup of group trees done ten days ago (the backup done since then had the new version of the tree). and went back to my old version of JabRef (2.11b4). This recovered use of group trees, although all the work done linking entries to them in past ten days lost.
I understand the policy shift regarding groups in newer versions of JabRef. It seems I must await the a fix for issue 1495 before venturing a JabRef upgrade.
I relaxed too soon! My old version of JabRef no longer works. I can no longer open entry tables. Double clicking an entry does not open it. Focus Entry Table does nothing. Toggle Entry Preview does nothing. I retreated to 2.11b2 and that version works OK, and so it appears my experiment with JabRef 3.8.1 damaged the .b4 .jar file. But restoring a backup did not help, and so it seems that an external file associated with 2.11.b4 was damaged.