Skip to content
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

Grouping by searching for keywords within customized fields #8527

Closed
2 tasks done
shivaway opened this issue Feb 23, 2022 · 33 comments
Closed
2 tasks done

Grouping by searching for keywords within customized fields #8527

shivaway opened this issue Feb 23, 2022 · 33 comments
Labels
bug Confirmed bugs or reports that are very likely to be bugs entry-editor groups keywords status: stale

Comments

@shivaway
Copy link

JabRef version

Latest development branch build (please note build date below)

Operating system

Windows

Details on version and operating system

Version 10.0.19044.1526

Checked with the latest development build

  • I made a backup of my libraries before testing the latest development version.
  • I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

  1. Create a new group using "Searching by Keyword".
  2. Use the Field Name of Entrytype
  3. Use the search of Report
  4. The group will find nothing, even though two items are there.
    test.zip

Appendix

...

Log File
Paste an excerpt of your log file here
@ThiloteE
Copy link
Member

ThiloteE commented Feb 23, 2022

Have i not solved this here: #8524 ? Is this the same problem @shivaway ?

@shivaway
Copy link
Author

shivaway commented Feb 24, 2022 via email

@shivaway
Copy link
Author

shivaway commented Feb 24, 2022 via email

@ThiloteE
Copy link
Member

ThiloteE commented Feb 24, 2022

if you have an entry like this:

@calibration{test,
  entrytype = {protocol},
}

searching by keyword protocol will still find this entry.
searching by keyword calibration should not find this entry.

That is because the keyword search was configured by you to not actually search for the "entrytype", but rather for the data within the FIELD "entrytype".

I am not sure if it would be possible to search for the actual entrytype. I think current Jabref does not supports this.

@shivaway
Copy link
Author

shivaway commented Feb 24, 2022 via email

@Siedlerchr
Copy link
Member

You have to post images here on GitHub they are not visible when you answer via mail

@shivaway
Copy link
Author

Sorry, I tried to post the following showing what was happening.
1645734423318blob
1645734464735blob
1645734494055blob

@ThiloteE
Copy link
Member

So i take it this issue is solved?

@shivaway
Copy link
Author

shivaway commented Feb 24, 2022 via email

@ThiloteE
Copy link
Member

You know, hope is the greatest of all treasures 🤣

Anyway. i think it would be nice if you could upload the data of the entries here. They example file you uploaded in your first post holds different examples that are different to the pictures you show us.

@ThiloteE
Copy link
Member

ThiloteE commented Feb 24, 2022

In the first example you uploaded none of the entries hold such a field: entrytype = {Report},

Therefore, the following statement is incorrect, because the items are NOT there:

4. The group will find nothing, even though two items are there.
test.zip

As soon as i add entrytype = {Report},, it will be added to the group.

I repeat, you are confusing entry type and entrytype. To make it more clear to you: One of them is a custom entry type defined under options>customize entry types and the other one is a custom field you added to this type of entry. Both are not the same. You also could have named the custom field entrytypeX or XYZ or ANYTHING and then put the keyword Report in there. So when you have a group that searches for the keyword report within a custom field that is called XYZ, it will find the entry and add it to the group, even though it will not look like it is the entrytype,

Searching for a keyword searches for data within a field. It does not search for an entry type. So if the entry type is report, but the field is missing, it will not be added to the group.

@shivaway
Copy link
Author

shivaway commented Feb 25, 2022 via email

@ThiloteE
Copy link
Member

image

@ThiloteE
Copy link
Member

But i also have to say that you might be right that something is off there.

Using your library from here:

  1. When the keyword is report (hence within the group) and i change the keyword to xyz the entry gets removed from the group. Then when clicking UNDO (ctrl + z) three times, the entry is back in the group, but the keyword is still xyz, even though it should be report.

  2. Even worse, when I change the keyword of the entry with citationkey Calibration2021 from protocol to xyz (the entry gets removed from the group; This is correct), but then click on another entry, then back on that one entry where i just changed the keyword, the keyword IS BACK to what it was before i changed it (still protocol) in the required fields tab, but still xyz in {} bibtex source tab!

@shivaway, could you try to name the field entrytype differently e.g. customentrytypelabel or entrytypekeyword? Maybe it conflicts somewhere with the actual internal entry type after all?

@shivaway
Copy link
Author

shivaway commented Feb 25, 2022 via email

@shivaway
Copy link
Author

I think it does have the conflict. I added a new field to each of the types called customentrytype and changed the reports to use customentrytype for the search and it now reports 5 instances. It contains the two reports but still contains all the protocols, none of which have "Report" in any field. In fact, that type doesn't even have the customentrytype field. I'm uploading the current .bib
Screenshot 2022-02-25 081101
test.zip

Something weird is definitely going on.

@ThiloteE
Copy link
Member

Just for the record, when i try to import your library, i get this message:

image

@ThiloteE
Copy link
Member

ThiloteE commented Feb 25, 2022

When I opened the last library file you posted, all three of the entries with entry type Protocol, had report in customentrytype. Therefore, the second part of the following sentence is not true:

It contains the two reports but still contains all the protocols, none of which have "Report" in any field.

@ThiloteE
Copy link
Member

ThiloteE commented Feb 25, 2022

What we found out so far point to three things:

  1. Jabref fails at reading and depicting the keyword from a customized entry field within the required fields entry editor tab under certain circumstances (see this comment)
  2. You could have misconfigured Jabref, because whenever i try to import your library, there is something missing and the library does not fit to what you say here on github.
  3. If you configured Jabref correctly, it could mean that exporting/saving your library saves different data than what you expected.

That said, 1. and 2. is beyond my abilities. I could test a little bit more with regard to 3, but i really should work on my own paper right now xD

@ThiloteE ThiloteE added entry-editor groups keywords bug Confirmed bugs or reports that are very likely to be bugs export / save labels Feb 25, 2022
@ThiloteE
Copy link
Member

Also, please change the name of this issue to something that makes this issue easier to find for people that have similar issues.

E.g.: Grouping by searching for keywords within customized fields

@shivaway shivaway changed the title Grouping on Entrytype with Grouping by searching for keywords within customized fields Feb 25, 2022
@shivaway
Copy link
Author

shivaway commented Feb 25, 2022 via email

@Siedlerchr
Copy link
Member

@ThiloteE Custom entry type information is written to the bib file at the bottom in the metadata, like the groups etc
The other thing sounds like a bug/inconsistency with the Undo/Redo

@ThiloteE
Copy link
Member

Thanks Christoph, i might do some tests one of these days.

@shivaway check github, i uploaded a picture.
image

@shivaway
Copy link
Author

Interesting. Looking at the source, I can see the error and have no idea why I put "Report" for Customentrytype. What's even more fun is the non-customized entryetype has three items, when on the edit screen, I can see only one.
Screenshot 2022-02-25 162001

This is from the zip file I sent over.

Thanks again!

@ThiloteE
Copy link
Member

I cannot reproduce neither the undo, nor the other phenomenon described in #8527 (comment) and also not the "one keyword in edit screen while there are three keywords in {} bibtex source" issue with a minimal working example within a fresh library (here, the library that does not reproduce), but i can reproduce it when i use the library you uploaded (here).

There seems to be a special factor at play that we seem to have failed to identify so far. Your library seems special.

@shivaway
Copy link
Author

shivaway commented Feb 26, 2022 via email

@ThiloteE
Copy link
Member

ThiloteE commented Jun 16, 2022

To do:

Read and understand #8527 (comment)

Then:

Alternatively:

@LIM0000
Copy link
Contributor

LIM0000 commented Jun 21, 2022

From image in #8527 (comment), I believe this was not a misconfigure.
Please read #8911 (comment). The image is the result of user "forcefully" assign entries into WordKeywordGroup via warning dialog asking users whether they would like to assign the original group's entries to this group.

image

@LIM0000
Copy link
Contributor

LIM0000 commented Jun 21, 2022

@ThiloteE , for second issue from #8527 (comment), I could not find entry with citationkey Calibration2021 in library from here.
Could you please write reproduce steps for me to recreate the issue?
Thanks a lot.

@ThiloteE
Copy link
Member

ThiloteE commented Jun 21, 2022

Ah my bad. I must have had automatic creation of citationkeys enabled back then.

I just tried again: I still can reproduce the second issue in #8527 (comment) for two entries that are in the group "Qualifications". Just go to the "other fields" tab, then look for "entrytype" and change protocol to xyz. Upon deleting one character, the entry will leave the group. So you have to go to "all entries" to finish the process. When you are done, click on another group or entry and you will see that the entrytype is still protocoll in the "other fields" tab, even though in {} biblatex source tab it will be xyz.

@LIM0000
Copy link
Contributor

LIM0000 commented Jun 21, 2022

Thank you @ThiloteE , here is a way to replicate the second issue using fresh library.

  1. Create a new library
  2. Go to Options -> Customize entry types
  3. Select Article and click on the drop down list. Please note that there is no Entrytype field available in the drop down list.

111

  1. Type in Entrytype and click on + button

222
333

  1. Create 2 new articles
  2. Navigate to Optional fields.

555

  1. Delete the value in Entrytype at Optional fields
  2. Select second entry and reselect first entry
  3. The Article value is back in Entrytype at Optional fields. However, it is being deleted in bibtex source.

My first guess to this issue is that there is an internal EntryType variable that does not allow user to modify it.
However, I could confirm that this second issue does not relate to #8527.
Would really appreciate if it could be moved as separate issue ticket.

@ThiloteE
Copy link
Member

ThiloteE commented Jun 21, 2022

Closing this.

It is very very very likely all issues here are caused by a toxic combination of issues

#8917 and #8911 Edit: and also #8824

Thank you for your report @shivaway and your patience!
Special thanks to @LIM0000 for helping to debug this! :))

@shivaway
Copy link
Author

shivaway commented Jun 21, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bugs or reports that are very likely to be bugs entry-editor groups keywords status: stale
Projects
None yet
Development

No branches or pull requests

4 participants