-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected behaviour: Groups search - Item assignment #3176
Comments
I took a quick look at this, but am not sure what you're referring to. Do you mean the 'groups interface' and the 'filter groups' feature that's located on the bottom of that pane? |
Yes, indeed: |
I tried it out by your steps, but dont see that same issue. When I filter and select another group I still see my previous selection and can add it to that group. I did find a defect while looking at this though, when you rename a group through the edit group option it doesnt get renamed in the group editor, only in the actual items that belong to that group. |
I've tried it again with: I can confirm your observation, that the originally selected item is still selected (indicated in blue). The problem, however, is, that this item is not found at the top of the non-group items (displayed in gray), but is found somewhere hidden among other non-group items. This is not a major problem, if you only have a small database, but mine contains several thousand items. Therefore it gets very difficult to find again the item you initially selected (this is also the reason, why I initially thought that the selection had been lost). |
This issue persists in: JabRef 5.0-dev--snapshot--2018-10-28--master--05047f32a This issue is potentially connected to the fact that currently non-group items are not shown in the main table (not even in gray; see #4237). |
See also the comment here: |
I can confirm the same behaviour in: |
JabRef 5.3--2021-01-04--10180ed The issues as described in #3176 (comment) (with the updates from #3176 (comment)) persist in the current developer version of JabRef. |
JabRef 5.4--2021-12-10--eff8073 This issue reported in in #3176 (comment) (with the updates from #3176 (comment)) persists in the current dev version. Please reopen! |
Thanks to @LIM0000 this issue is now resolved in the latest development version. We would like to ask you to use a development build from https://builds.jabref.org/main and report back if it works for you. Please remember to make a backup of your library before trying-out this version. |
JabRef 5.7--2022-05-30--3222878 I am afraid, this issue persists in the current development version as far as I can tell. Note also, that it is currently difficult to verify the persistence of the issue, since the floating mode has been lost in the new versions of JabRef (though people are working to get it back: #8206 (comment)). However, since the selected item is even invisible when the "All Entries" group is selected, I reckon this problem persists as described in #3176 (comment) |
JabRef 5.11--2023-10-17--8ede31a I am afraid, this issue persists in the current development version as far as I can tell. Note also, that it is currently difficult to verify the persistence of the issue, since the floating mode has been lost in the new versions of JabRef (though people are working to get it back: #8206 (comment)). However, since the selected item is even invisible when the "All Entries" group is selected, I reckon this problem persists as described in #3176 (comment) with updates from #3176 (comment) @koppor Can you please re-open this issue? |
Try with a large database with thousands of entries and groups the following: Steps to reproduce:
As mentioned in #3176 (comment) the originally selected item is (probably? - I cannot see this in my large database atm) still selected (indicated in blue). The problem, however, is, that this item is not found at the top of the non-group items, but is found somewhere hidden among other non-group items. This is not a major problem, if you only have a small database, but mine contains several thousand items. Therefore it gets very difficult to find again the item you initially selected. |
Ah now I better understand your problem. Yes, it's a bit cumbersome. But once the item is selected (no matter where, it stays selected) and you filter or select a group it will be added |
I am adding here a video to showcase the problem. Note, how the selected item turns "invisible" once the new group is being filtered for. This makes it impossible to drag'n'drop your selected item to another group, which obviously would be something you definitely would like to be able to do with the nice group filtering option. Groups_search_Item_assignment_JabRef_5.mp4Given that the issue description as it stands now slightly differs from the original one. Should I open a new bug report in regards or should we re-open this one? EDIT: And as far as I can tell using "Add selected entries to this group" also does not work, if you follow steps 1 to 5 and then attempt to add the item to the group via the right click menu item. It shows the menu "Add selected entries to this group", but clicking onto it does not add the item to the group. |
JabRef 4.0-dev--snapshot--2017-08-31--master--54e0994ba
Windows 10 10.0 amd64
Java 1.8.0_141
Steps to reproduce:
This behaviour is unexpected, as it does not allow you to quickly assign one item by using the groups search feature (i. e., search group -> select item -> search another group -> assign item to it). Instead you have to assign the group the "old-fashioned" way, i. e. either by drag'n'dropping it to the group of interest OR by using the menu associated with the group OR using both the item and the group search feature.
Just using the groups search feature alone won't do the trick, currently.
The text was updated successfully, but these errors were encountered: