JabRef version
5.7 (latest release)
Operating system
GNU / Linux
Details on version and operating system
Ubuntu 22.04 LTS
Checked with the latest development build
Steps to reproduce the behaviour
- Create a new library and add at least two bib entries
- Sort your columns by ranking (highest ranking first)
- Set the ranking of the second entry to any rank: It should now be on top (as the other entry has a ranking of 0), but the position does only change after another change in the UI (e.g. setting the read status or setting a different rank value).
To be more precise, I inspected the code and found that the RankingFieldComparator always gets called with the old rank value, not the updated one. This is due to BibEntryTableViewModel which has both, the BibEntry entry and Map<SpecialField, OptionalBinding<SpecialFieldValueViewModel>> specialFieldValues attributes. The RankingFieldComparator is getting called with the value returned by public ObservableValue<Optional<SpecialFieldValueViewModel>> getSpecialField(SpecialField field) of the BibEntryTableViewModel object. This method returns the value from the specialFieldValues attribute, which, however, has not yet been updated as the comparator is called. The BibEntry entry field has in fact already been updated, which enables the following (dirty) workaround:
public ObservableValue<Optional<SpecialFieldValueViewModel>> getSpecialField(SpecialField field) {
OptionalBinding<SpecialFieldValueViewModel> value = specialFieldValues.get(field);
// Fetch already updated value from BibEntry entry
Optional<String> currentValue = this.entry.getField(field);
if (value != null) {
// BEGIN WORKAROUND
if(currentValue.isPresent()) {
if (!value.getValue().get().getValue().getFieldValue().equals(currentValue)) {
value = getField(field).flatMapOpt(fieldValue -> field.parseValue(fieldValue).map(SpecialFieldValueViewModel::new));
specialFieldValues.put(field, value);
return value;
}
}
// END WORKAROUND
return value;
} else {
value = getField(field).flatMapOpt(fieldValue -> field.parseValue(fieldValue).map(SpecialFieldValueViewModel::new));
specialFieldValues.put(field, value);
return value;
}
}
I am new to JabRef, so I am not sure, why the extra specialFieldValues is actually needed, given that these values are already included in the BibEntry entry itself.
I like JabRef very much and am currently using it for my thesis, it is however a bit annoying to be forced to set the ranking twice by triggering the UI again. I would also be happy to create a PR for this myself, however, as already mentioned, I think that the "root cause" for the problem is nested a bit deeper, so more information would be necessary and much appreciated :)
JabRef version
5.7 (latest release)
Operating system
GNU / Linux
Details on version and operating system
Ubuntu 22.04 LTS
Checked with the latest development build
Steps to reproduce the behaviour
To be more precise, I inspected the code and found that the
RankingFieldComparatoralways gets called with the old rank value, not the updated one. This is due toBibEntryTableViewModelwhich has both, theBibEntry entryandMap<SpecialField, OptionalBinding<SpecialFieldValueViewModel>> specialFieldValuesattributes. TheRankingFieldComparatoris getting called with the value returned bypublic ObservableValue<Optional<SpecialFieldValueViewModel>> getSpecialField(SpecialField field)of theBibEntryTableViewModelobject. This method returns the value from thespecialFieldValuesattribute, which, however, has not yet been updated as the comparator is called. TheBibEntry entryfield has in fact already been updated, which enables the following (dirty) workaround:I am new to JabRef, so I am not sure, why the extra
specialFieldValuesis actually needed, given that these values are already included in theBibEntry entryitself.I like JabRef very much and am currently using it for my thesis, it is however a bit annoying to be forced to set the ranking twice by triggering the UI again. I would also be happy to create a PR for this myself, however, as already mentioned, I think that the "root cause" for the problem is nested a bit deeper, so more information would be necessary and much appreciated :)