This set of commits add import from local accounts.
It's a bit rough around the edges, but it's good enough to go in, so work can continue
collaboratively.
The crypto class now behaves differently depending on the version of the
journal.
The current difference is in the key derivation, and that the new
version of the crypto also hmacs the version automatically whenever it
hmacs anything.
The versioning was added for better future-proofing of the code.
The derivation change was done because before we were creating the same
password for all of the journals, now we do it per-journal. This means
that we can, if needed in the future use this password as the journal
password when sharing journals without compromising the security of the
rest of the journals.
The app update broadcast receiver is only called on the first update,
not install, which was causing EteSync to think it was updating from
version 1 on the first update, doesn't matter which version one was
updating from.
This fixes it by saving the version on the first run.
Before this change we were adding them to cache before they were
processed, potentially persisting malformed entries, or entries we
haven't yet processed causing issues if sync was aborted before an entry
was fully processed.
Commit 5d1c90dcba fixed a bug where
entries added from the server were marked as "local only" (null etag)
which was causing issues. That commit fixes it for newly added resources,
but existing resources remained broken.
This commit goes through the database and fixes all of the existing
broken resources. It skips dirty entries because figuring out if they
were just created or updated is complex, and the chances of doing an
update at exactly the same time there are dirty entries is quite low,
so the complexity involved is just not worth it.
Before this commit we would create new entries from the server without
an etag, essentially marking them as "local only". While the actual
value of the eTag is not currently used, null or not matters.
Because the resources were "local only", we would get weird behaviours
like having an "ADD" action when changing a resource.
Before this change we would only add "deletes" to the server when the
resource has been previously uploaded. This means that if a resource has
been created and then deleted before a sync, it would not be saved,
which is essentially data-loss.
This commit fixes it, so we always upload a delete entry.
It's really annoying that it doesn't do it automatically as it should,
in the meanwhile, add this workaround.
I reported it to upstream:
https://github.com/requery/requery/issues/487
Clearing the cache is a good idea regardless, though because of the
unique constraints in the cache on the journal name, this was causing
issues when deleting an account and then adding it back.
It's very raw and hacky at the moment, it's just a preview release so
people could see their data is saved, and can look at it in its raw
form until we implement a nicer view.
Before this commit it was only used to override the api endpoint,
not it's also used to override the weburl. This is needed since we now
load the etesync website inside the app and not in an external web
browser.
Without this change, if the putting on server of a new collection fails,
the url would already be updated, and since having a url indicates it
exists on the server, trying to save it later would result in a 404.
Adding this because users were asking about the history feature. While
the history is maintained, there's currently no GUI to explore it, so
I've added this stub to make it more obvious that it's not there yet.
Before this commit the texts were different, and odd.
For example, the text in the selector would be:
Every 4 hours
and the text in the preview would be:
Every 240 minutes
This follows the previous change and puts more information in the
exceptions (like parts of the http request and response) for better
debugging. This also moves the handling of "retry after" to the
exception itself instead of outside.
Also improved the text of one of the exception invocations.
Before this change exceptions would print the message of the error code.
For example, for 500 they would print "Internal Server Error".
With this change we can now override this message with something more
sensible we got from the serer, for example "User is inactive."
This is a possible error message we get when we get error code 403
(permission denied) from the server. We then handle it explicitly by
sending the user to the dashboard.
With this change we no can launch external urls. For all I know this
doesn't work without this trick (an intent in the middle).
I also applied a transparent theme to the activity to avoid seeing the
launched activity briefly before opening external urls.
This is based on my experience working on "Share To Clipboard".
I was trying to avoid it, and keep it as davdroid both for attribution,
and making it easy to cherry-pick fixes from DAVdroid.
However, it seems to be causing clashes with the davdroid app, although
every piece of documentation claims otherwise.[1]
At least it seems like cherry-picks can still be achieved using:
git cherry-pick -s recursive -X find-renames=30 COMMIT
1. https://developer.android.com/studio/build/application-id.html
(one such doc)
