You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
File rename commands are greyed out and not active, and the reason is not clear for the user. Moreover, these commands are inactivated at the moments when they are badly needed!
Steps to reproduce the behavior:
Start the relevant version of the JabRef;
Load some .bib library; the file used for testing is in the .zip below: new.zip
Populate directory "new/" with some OA PDFs having the same names as in the .bib file;
For testing, the following settings were used:
-- Autolink files: use regular expression **/[year]_[auth].*\\.[extension];
-- File format pattern: [year]_[auth]_[firstpage];
-- File directory pattern: by-author/[authIni1]/[auth];
Right-click on the file linkage box in the entry editing window;
For version 5.2, both "Move to file directory..." are always disabled, but "Rename to a defined pattern" is active and works:
In 5.3 and 100.x (the current master tip), the "Rename to a defined..." and "Move to file directory and rename..." are enabled at the beginning, but are disable after the first rename, with now means to reenable them except shutting down the whole JabRef and starting it again. Changing the BibTeX entry (e.g. adding page numbers, that potentially change the "defined name pattern") does not re-enable these fields:
Either the commands should be re-enabled after edit, or not disabled at all; otherwise the renaming feature (which I use a lot!) becomes next to unusable...
The text was updated successfully, but these errors were encountered:
Hi @sauliusg , I think I located the problem and fixed it. Would you be so kind to test the build at https://builds.jabref.org/pull/7548/merge/ if this works for you? Be aware that this is a development build, so please backup your database first.
Also I saw that changing the default file link name pattern in the preferences requires a restart to take effect. This is probably a bug for later - since refactoring the preferences is a major background issue. But the menu entry should be enabled again if you change the entry.
Most important is that you can continue to work with your library.
Hi @sauliusg , I think I located the problem and fixed it. Would you be so kind to test the build at https://builds.jabref.org/pull/7548/merge/ if this works for you? Be aware that this is a development build, so please backup your database first.
I can confirm that 'JabRef-5.3-portable_linux.tar.gz' from the above directory works as expected. The file renaming functions are active; renaming or renaming and moving to the destination directory work as expected. After that they are greyed out, but editing the entry (changing page numbers or author name) re-enables them again. So far everything fine.
Also I saw that changing the default file link name pattern in the preferences requires a restart to take effect. This is probably a bug for later - since refactoring the preferences is a major background issue.
I tested with my pre-configured patterns from JabRef-5.2 configuration, and it works. I'll check later how changing the pattern(s) influences the functionality.
But the menu entry should be enabled again if you change the entry.
Indeed, it is.
Most important is that you can continue to work with your library.
JabRef version 5.2, 5.3 and 100.0.0 (commit 0dd4de7) on Linuxmint-20.1 and LinuxMint-19.3.
File rename commands are greyed out and not active, and the reason is not clear for the user. Moreover, these commands are inactivated at the moments when they are badly needed!
Steps to reproduce the behavior:
new.zip
-- Autolink files: use regular expression
**/[year]_[auth].*\\.[extension]
;-- File format pattern:
[year]_[auth]_[firstpage]
;-- File directory pattern:
by-author/[authIni1]/[auth]
;Either the commands should be re-enabled after edit, or not disabled at all; otherwise the renaming feature (which I use a lot!) becomes next to unusable...
The text was updated successfully, but these errors were encountered: