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

"Printed" and "Readstatus" are not remembered, when removed from "Keywords" #6621

Closed
1 task done
StephanJohn opened this issue Jun 19, 2020 · 5 comments · Fixed by #6846
Closed
1 task done

"Printed" and "Readstatus" are not remembered, when removed from "Keywords" #6621

StephanJohn opened this issue Jun 19, 2020 · 5 comments · Fixed by #6846
Assignees

Comments

@StephanJohn
Copy link

StephanJohn commented Jun 19, 2020

JabRef 5.0--2020-03-06--2e6f433
Windows 10 10.0 amd64
Java 13.0.2

The special fields Printed and Readstatus do not work independently of the Keywords field:

I added the Printed field to show up in the main table. If I click the printer icon next to an "article" entry, JabRef adds the word "printed" to the Printed and the Keywords fields. Because I would like to use my Keywords field for other purposes, I delete the word "printed" from the Keywords field.

If I now close the file and re-open it, the "printed" entry is lost from the Printed field. But only if the Keywords field contains other entries. If Keywords is empty, "printed" is not lost!

(The same is true, I noticed, for the ReadStatus field - I haven't tested any other fields.)

Steps to reproduce the behavior:

  1. Make sure to have a database entry with non-empty Keywords field.
  2. Set "printed" status to true.
  3. Remove "printed" from the Keywords field.
  4. Save file.
  5. Reopen file.
@Siedlerchr
Copy link
Member

Hi there is a setting in the preferences, sync special fields to keywords. I guess this setting is enabled and causes the behavior

@mlep
Copy link
Contributor

mlep commented Jun 19, 2020

Shouldn't the checkbox "sync special fields to keywords" be unchecked by default?
It is not obvious for a user that special fields and keywords are/should/need to be linked, and this leads to confusion.
My guess is that the principle of least surprise would recommend not to link by default these two features.
Another to tackle th issue:

  • why do they need to be linked?
  • why do they need to be linked by default?

@koppor
Copy link
Member

koppor commented Jun 29, 2020

I remember our internal discussion, that we should migrate the functionality to the groups feature. Therefore tagging as "jabcon".

The development history is that at the introduction of the feature, the developer was not sure what's best: keywords or seperate fields. Some were arguing that "keywords" should be the ones provided by the publisher and not be modified (at all costs). Others were arguing that keywords are the sole realm of the user.

To the concerete case: The preferences allow only one of the two cases:

grafik

Thus, this really seems to a bug.

@koppor
Copy link
Member

koppor commented Sep 2, 2020

Decision:

  • For JabRef 5.2, we change the default to "not sync".
  • We will offer a migration from keywords to special fields

@StephanJohn May I ask how you configured JabRef?

@StephanJohn
Copy link
Author

@koppor: I hadn't been aware of the "sync keywords to special fields" option, so this had been set to "enabled" by default.

koppor pushed a commit that referenced this issue Aug 15, 2023
795ad0c772 Create duale-hochschule-baden-wurttemberg-department-of-international… (#6622)
18ee055259 Create Howard Hughes Medical Institute  (#6615)
ad5bedc1d2 Update the-journal-of-clinical-investigation.csl (#6607)
6a938ccd0e Update haute-ecole-de-gestion-de-geneve-iso-690.csl (#6621)
289fda356b Update haute-ecole-de-gestion-de-geneve-iso-690.csl (#6620)

git-subtree-dir: buildres/csl/csl-styles
git-subtree-split: 795ad0c77258cb7e01f3413123b5b556b4cb6a98
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants