-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Fixes #1482: Correct number of matched entries is displayed for refining subgroups #1483
Conversation
… refining subgroups The issue was that, for the number of hits, JabRef only checks if the group taken separately matches the entry. That is, it is completely ignored that the group sits in a tree and might be set up to refine the search of the parent. Taking the example given in JabRef#1482, 577 entries satisfy the condition `articlé original` but only 38 are also matched by `articlé`.
LGTM 👍 |
assertEquals(2, node.numberOfHits(entries)); | ||
} | ||
|
||
// Test for #1482 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unnecessary comment in my opinion. Doesn't matter for which issue this test is. The test covers the old problem.
LGTM 👍 |
} | ||
} | ||
return hits; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this moved? I think it fits more into the group itself which carries around the search rule. Maybe this should even be moved to a search matcher?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The (Abstract)Group does not know where it is sitting in the group tree but the GroupTreeNode does. But the position in the tree might influence the search result (since we support refining / independent / ... search modes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok, the getSearchRule is automatically adjusting to the position in the group tree? Then this make sense.
LGTM |
Ok, let's merge this in 😄 👍 |
The issue was that, for the number of hits, JabRef only checked if the
group taken separately matched the entry. That is, it was completely
ignored that the group sits in a tree and might be set up to refine the
search of the parent. Taking the example given in #1482, 577 entries
satisfy the condition
articlé original
but only 38 are also matched byarticlé
.