jabref: Duplicate groups in an input file are not detected

I’m not sure why you would like to search for groups = .... In this case it’s probably easier to just select the group in the tree… Let’s not worry about this too much until users report they use this often for reason xyz. (Except if I’m missing an important use case)

Well, I use this all the time, since finding the group in the tree takes much longer if you have to go through thousands of groups. So, this is a real use case.

Thanks for the ongoing discussion. The twitter poll clearly showed that many users would like to have groups with the same name. However, it became also clear that it might be confusing if the entries are automatically shared. In the devcall we also discussed that there are also scenarios where the groups with the same name actually don’t show the same entries (e.g. if one uses the hierarchical modifiers), potentially leading to even more confusion.

For this reason I would strongly propose to go the id-based solution:

• Each group gets an unique identifier
• The identifier is stored in the groups field (and no longer the name of the group)
• Users can create completely independent groups with the same name (even in the same hierarchy level if they desire, although a warning should be shown in this case)
• In case, they want to have a mirror group they can use an automatic keyword group pointing to the groups field and searching for the identifier of the other group.

This unique identifier will also be very helpful for other scenarios. For example, we are planning a new feature in connection with JabRef Online, where users can share a group. For this a unique identifier is essential, since one needs to a way to identify the group even for different users.

@sauliusg your work here in this PR is very much appreciated. But I think the id-based system is the more universal way forward. Would you be interested in implementing it? We core developers help of course where we can!

I agree with you that it sometimes could be advantages to have the same group in two different places. However,

subgroup can also belong to several different super-groups (together with all papers assigned to it)

is a highly unusual concept from a user-interface perspective. For example, files with the same name but in different folders don’t automatically sync their content. I think we should really stick to the tree nature of the group interface, meaning that groups are independent.

As a way forward, I would propose the following:

• Allow to have groups with the same name in different positions. I.e. properly fix https://github.com/JabRef/jabref/issues/1495. Warning: this is might be very complicated.
• Once this is done, we can think about adding a “symlink” group that acts as a copy of a different group.

What do you think? Help on this of course very much appreciated.

So lets sum up the current situation:

1. The current group implementation has useful features (nicely summarised in #629: independence of BibTeX entries, possibility to manually edit BibTeX file for grouping, among the others);
2. Users want flexible hierarchy and want to be able to create groups with whatever names they want, without a tool standing in their way;

A possible (easy?) way to reconcile these two requirements could be:

• JabRef supports (as it already does now!) groups with identical names anywhere in the hierarchy; no changes is needed here, just the promise that the future versions of JabRef will not “disallow” such use of JabRef 😃;
• The GUI allows creating such groups if the user wants to (so that we do not have to save the database, close JabeRef, edit the file by hand, restart Jabref every time I want the group that has a name already in the hierarchy). For this and the following functionality, a change would be needed in JabRef but the change will be small and localised (affecting, presumably, only the group creation dialogue).
• The GUI warns the user that the group already exists elsewhere in the hierarchy, and that of created this group will contain the same entries as all other groups with the same name (I estimate that 50% cases this is what is actually needed);
• The GUI suggests a unique name based on the hierarchy, by appending previous levels of the tree, and possibly numbering, until the name becomes unique; a user can chose that name by a single click or can continue using the duplicated name (with merged entries.

Example:

Groups:
Bioinformatics
- Drug design
-- Diabetes
--- Treatment
Medicine
- Diabetes mellitus
-- Treatment
- Diabetes
-- Treatment
- Asthma

When creating a subgroup called Treatment in Asthma, the GUI could respond:

Warning:
A group named 'Treatment' already exists in 'Medicine/Diabetes/Treatment', 'Medicine/Diabetes mellitus/Treatment'. 
If you create the group 'Treatment' here, it will contain entries from all mentioned groups.
[x] Use a unique name 'Treatment (Asthma)'
[OK] <- the button is *always* active!

I deliberately suggest using ‘Treatment (Asthma)’ instead of ‘Asthma/Treatment’ to avoid impression that the group name is strictly bound to group’s position in the hierarchy. It is not; so moving group ‘Treatment (Asthma)’, say, one level up to ‘Medicine’ would not make its name “incorrect”, in the sense that the group still contains papers about asthma treatment no matter where in the hierarchy it resides. This also means that JabRef does not need to bother about renaming groups when their position in the hierarchy changes (as is implemented now).

The suggested change would:

• mostly solve most peoples problems with the current group implementation;
• make the suggested workaround for group uniqueness more usable;
• Add additional capability to JabRef (at no or very little implementation cost!) that would allow the same group to be placed in different parts of the hierarchy; a use case demonstrated by my SQL example shows that this can be very useful.
• Explicit warnings in group creation dialogue and complete information about the same group names wold remove (most of) the confusion.