This splits up the RemoteDatabase class into two classes, RemoteDatabase
and RemoteNetwork. The first is for managing the directory of cloned
databases while the second is for network handling only. Moving the
network code into a separate class requires some rewriting but should
make the code easier to maintain and extend.
This adds a new context menu action to the commit list in the Current
Database tab of the Remote dock which downloads the database from that
commit and saves it to another file. This file can then be opened and
inspected just like any other database file and does not update the
local clones data.
After opening a clone of a remote database, allow checking out the
different branches and commits of this database in the Current Database
section. This way you access all branches and see their history in DB4S.
Add a toolbar to the Current Database tab of the Remote dock with one
button for now. This button opens the web page of the currently opened
database in the browser.
Also reduce the margins in the Remote dock a bit.
Highlight the last locally known commit id in the commit list in the
Remote dock. This should make it more obvious whether there are any
newer commits on the server.
When opening a clone of a remote database show a list of all branches,
releases, and tags in the Remote dock and show the commit list when
selecting one of them.
If the current database file is a clone of a remote database show some
information on it in the Remote dock. Even though this information is
already nice to have the new tab in the Remote dock is mainly added as a
place for future features. Also switch to the new tab automatically when
opening a remote database to show the user that this is a tracked
database.
The Remote dock shows a list of all databases on dbhub.io. Double
clicking a database downloads and opens it. If the database has already
been downloaded before, the local file is simply opened. This only works
for a small number of databases: To open the database you want, you just
search for it and double click it. But for a larger number of databases
on dbhub.io this does not perform very well since finding a database can
be very difficult. Because of this this commit adds a new view which
shows all checked out databases, i.e. those databases which are already
downloaded. Double clicking one of these opens it without trying to
update it first.
In the future this might also provide a place to add extra options like
deleting local copies.
This adds initial support for handling of different branches. Before
this we would always assume we were working with the master branch even
if in fact we were not. Now we respect the actual branch name and
support checkouts of different branches of the same database.
Respect the suggested order of the licences as provided by the dbhub.io
server instead of sorting them alphabetically by their internal key.
Also remove the hard-coded "Unspecified" licence option because the
dbhub.io server provided its own "No licence specified" option.
We started to use Niels Lohmann's JSON library instead of the one
included in Qt for the Export JSON dialog a while ago because Qt's
implementation showed some problems. To avoid any similar issues and
because Niels' library has a much nicer API, this commit migrates all
our code to his library.
The automatic update check is performed early during the application
start. It turns out that, when using a Wifi connection, the Qt
networking code is not ready yet at this point which leads to an
"Network inaccessible" error. This commit delays the automatic update
check until the network configuration is loaded completely.
See issue #1595.
* Replace deprecated qt5_use_modules function
* Fix includes that fall under a larger module
* Bump minimum Cmake version to use newer features and properly use libs
* Replace deprecated qt5_use_modules function and bump minimum CMake version to 3.1.0 for 3rd party libraries
When pushing a local database to the remote server, the new commit id is
returned. Grab that id and insert it into the database of local
checkouts. If there already is an entry for the given file, update that
record. When doing an initial push of a database, also copy the source
database file to our checkout directory to avoid redownloading the file
upon first use.
This should eliminate all unnecessary database downloads, both after
doing the initial push and after committing a modified database.
If there is a local clone of a remote database but the remote database
has been updated to a newer version in the meantime, we're now asking
the user what to do. The choice is between downloading the newer version
and overwriting the local one with all the changes it might have
contained or opening the local version and not downloading anything.
See issue #1096.
This feature isn't explicitly available via the UI (yet) but should
prevent errors when the user is faster than the network connection, e.g.
when opening two directories very quickly.
This improves the user experience for pushing database files. Before
this you had to type in the entire URL for pushing, e.g.:
https://db4s-beta.dbhub.io:5550/username/databasename
With this the host name as well as the user name is taken from the
currently active client certificate. So all you have to type in now is
the database name. And for this we make a sensible automatic suggestion
based on the name of the local file you're trying to push.
Note that while this makes pushing databases a lot easier, it still
doesn't implement proper version control or any extra code for handling
conflicts etc.
This adds a local database to keep track of all the cloned databases.
For now we only use this information to prevent exactly the same
database being downloaded twice.
Move the network part of the automatic version check code into the
dbhub.io parts. While semantically this doesn't make a lot of sense it
simplifies the code a bit, reduces the size of the main window class,
and avoids duplication of code e.g. when introducing proxy support.
This adds a new dock to the main window that contains all the remote
functionality (or is supposed to contain it all in the future).
It also adds a directory browsing feature which allows you to browse
through the folders and files on the dbhub server.
By double clicking a database you can download and open it. The Open
Remote menu action isn't needed anymore and has been removed.
This also fixes an issue with pushing databases where, after sending the
file is completed, the save dialog was opened.
Note that this is still WIP and is far from polished.
When trying to fetch a database don't load a hardcoded client
certificate but grab one from the certificate manager in the preferences
dialog.
Also add support for password protected private keys.
Note: Since this is all testing code on the front-end side, we just use
the first certificate in case multiple certificates are configured.
Add a list of all configured client certificates to the preferences
dialog and show some information on them.
Add two button to the preferences dialog to add and remove client
certificates.
Copy configured client certificates to some safe place where they aren't
deleted by accident.
Change the remote code to expect certificate and private key in one
file. The path to this file is still hardcoded, now to client.cert.pem.
Remove the example client certificate as it's not up-to-date anymore
anyway.
Still missing: Option to use a configured client certificate from the
preferences dialog to authenticate.
Change the layout of the preferences dialog a bit.
Remove the server selection combo box from the preferences dialog as it
will probably never be required. The way we do logins using certificates
kind of makes this obsolete, I think.
Restructure the whole remote code a little bit. Also add helper
functions here and there.
Show a list of our the CA certificates built into the application in the
preferences dialog. This list is read only of course but still
informative as it tells the user which sites are supported ny DB4S.
This adds basic support for fetching databases via HTTPS using client
certificates. You can include CA certificates to verify any responses
from a server. For now, one test CA certificate is included but it's
easy to add more.
It's also possible to authentify the client using a client certificate,
a client key and a password. As of this commit all three items are
hardcoded.
It's still possible to access any remote database via HTTP but if a
request URL starts with 'https' this new mechanism will be used.
All certificates, keys, and password included in here are taken from my
node.js test server repository. They will be replaced soon-ish.
This adds some initial support for opening remote files. You can enter a
URL and DB4S will try to download the file. When successful you'll be
able to specify a place and name to save the file under, and after
saving it locally to disk it'll be opened just like any local database
file.
See the included TODO comments for missing features. Most notably
missing is the HTTPS and certificate handling code. Also any support
for storing the remote source of a database is lacking.
