Open last connected shared DBs at startup preference

[NS404]

Fixes #9714

Created a new preference tab called Shared Database

Added two new preferences to the JabRefPreferences class. One boolean for the checkbox and one list containing the last shared database IDs.

Compulsory checks

Beta Give feedback

An error occurred while loading your tasklist. Please try refreshing the page, or edit + save the issue body.

1. Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
2. Tests created for changes (if applicable)
3. Manually tested changed features in running JabRef (always required)
4. Screenshots added in PR description (for UI changes)
5. Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
6. Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[Siedlerchr]

Hi, just a hint, you only need to modify the en.properties file, the rest is managed by crowdin. See https://devdocs.jabref.org/code-howtos/localization.html#localization

Please do not add translations for other languages directly in the properties. They will be overwritten by Crowdin

[NS404]

Can we take advantage of the file opening feature to open shared databases as if we opened them from the UI?

My current solution adds another preference for opening last connected shared databases at startup but I thought maybe we can use the current preference that opens files at startup, since my implementation was based on it.

But... In the current state connecting to a shared db through a file results in a library that passes its changes to the server but can't be updated on demand (only opening and closing the file) because the action for pulling changes from the server is disabled (CTRL + Shift + R OR File > Shared Database > Pull changes from shared database). This is because the action is allowed only if the location of the activeDatabase(managed by StateManger, basically the currently selected tab's BibDatabaseContext) is SHARED.

In our case the context of the library tab is set from LibraryTab.createLibraryTab method, initally a temporary empty context until the dataLoadingTask (which is a BackgroundTask wrapping OpenDatabaseAction.loadDatabase method) has finished executing. The dataLoadingTask calls SharedDatabaseUIManager.openSharedDatabaseFromParserResult which opens a connection to the server by creating a SHARED location context. This context instance is what I think should be passed to the Library tab in order to enable the 'pull changes' action. I achieve this by attaching the context to the ParserResult as a field which is then passed from the dataLoadingTask to the LibraryTab.onDatabaseLoadingSucceed(ParserResult p) in order to assign it to the library tabs context. Currently the tab's context is created inside the ParserResult.getDatabaseContext() as a LOCAL context.

[calixtus]

Devcall

We quickly looked into the deeper issue, we believe it's complicated to solve this issue now, until we can resolve the issue with the multiple und chaotic database open actions (see #8298). So we think we close this one for now and eventually come back for this one. Thanks for your efforts anyway. Maybe a look into other Issues or Good First Issues provide some idea what to do next?