on windos absolute path does not have to start with / . Remove failing assert
when editing ignored files list.
Signed-off-by: Matthieu Gallien <matthieu_gallien@yahoo.fr>
The content of notifications on MacOS are not allowed to contain HTML
tags in it. Linux (Free Desktop) notifications may contain HTML tags
in their content. However, it is optional that the notification daemon
interprets the tags. The GNOME notification daemon does not interpret
HTML tags and even does not strip them off. KDE's daemon interprets
the tags. For now I think it's the best solution to remove the HTML
tags. In the future we should fire a action if the user clicks on the
notification and react on it and open the link then. This should work
on all platforms. But as this change involves working with the native
MacOS api and I don't have hardware for that at the moment for that I
will postpone it.
Fixes#2200
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
- This information is retrieved from the notifications endpoint.
- Add icons for the different pre defined status.
- Make functions available to QML to decide which status icon to display.
- Display the user status icon on the avatar and
move the online/offline connection status to the folder icon.
Signed-off-by: Camila <hello@camila.codes>
To better see what is going on when and if files are removed by the
client.
See also: #260, #1433, #2913
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
The bug does seem to just appear in special compiler
constellations. We're unsure why this fix works. To better see if this
fix works or if crashes still occur, we added some logging.
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
We should not rely on the product name because it is something the
user can change in the theming options on the server.
Fixes#3001
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
This adjustment is necessary because of the changes of the new account
wizard that were introduced with:
e0b7ef15b2
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
If the get job got an authentication required error on the account url
(not davUrl! at that stage we always get auth error there), then it is
safe to assume basic auth is used on the server. It is then kind of
pointless to use any other auth mode they will necessarily fail. Only
basic auth will do the job so force it.
Signed-off-by: Kevin Ottens <kevin.ottens@enioka.com>
This is necessary to be able to distinguish between "I decided on basic
by default" and "I didn't write any auth type". To make sure all the
jobs end up writing something we then implement the "I decided on basic
by default" in the slots connected to the job and we assert it in
checkAllDone()
Signed-off-by: Kevin Ottens <kevin.ottens@enioka.com>
There were a couple of shibboleth related enums left, since that auth
method isn't supported anymore remove the code tied to those enums. It
was dead code anyway.
Signed-off-by: Kevin Ottens <kevin.ottens@enioka.com>
Customizing of the palette will prevent the settings dialog from
display a dark theme correct.
Fixes#2993
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
Refactoring of User::isValueableactivity() because of changes
introduced with merge commit f17c52d.
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
When the client runs and a conflict gets detected, the sync engine runs
two times.
On the first run, the sync engine detects the conflict, marks the
file as a conflict and propagates that to the GUI. This leads to an
error notification with the original filename in the main dialog.
The sync engine runs then a second time. On this second run, the file
that originally caused the conflict is not anymore a conflict
file. Instead, the sync engine detects the conflicted copy and
propagates that file as a conflict to the GUI.
When opening the conflict dialog with the original file name (not the
conflicted copy) a crash happens. Usually, the two sync runs are really
fast, so the user does not notice the first notification. However, a
problem can occur if a conflict gets created while the client is not
running. Since then, the client does not do two sync runs. It does only
run once.
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
Added the configuration options
confirmExternalStorage
crashReporter
newBigFolderSizeLimit
useNewBigFolderSizeLimit
to the Windows registry
Signed-off-by: Marco Hald <marcohald@users.noreply.github.com>
Indeed the path we have is supposedly not fully qualified in case of a
sync folder which doesn't point to / on the remote end. But LSCOL works
with absolute paths on the server so make sure this is what we give it
out.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This got broken during the huge discovery refactoring. I wrongly passed
the mangled name as is out of discovery, but coming from listing jobs it
was fully qualified while the jobs at propagation time and the db expect
those paths to be relative to the remote folder.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise they won't be loaded automatically at startup leading to lots
of missing icons. Since they're now in a static library they need that
explicit loading.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The test utils library collects all dependencies that are needed for
tests and gets automatically linked with every test.
Signed-off-by: Felix Weilbach <felix.weilbach@t-online.de>
Compiling nextcoud gui as a separate library. This is needed to more
easily write tests. The whole nextcloud application can now be linked
against the tests.
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
I went full steam on making it all public which is not really required,
it's only really QtWebSockets we're after. Could always be fine tuned
later on if this works as expected.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This would only happen if the parent of the newly created folder would
be explicitly set to online only, hence why it went under the radar
previously.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This account object was really only used during the initialization phase
or for forgetting the sensitive data. So let's receive it as parameter
there and pass it on from job to job as needed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The OS might request the same file again if we take too much time to
fulfill a request. So in case it's queueing the same one again instead
of bailing out just fail the second one and let the first one finish
properly.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
In case we'd been to slow to fullfill or we're still processing a
cancelled request better not just crash. We still log the issue though.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This got broken previously when trying to reconcile during a
cherry-pick. This also repairs the case when the theme tells us the
default is to not select anything (not that we're using this right now
but in case we'd like to brand this).
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We now favor APPLICATION_ICON_SET to isBranded() regarding the decision
to use PNG or SVG for icons.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Indeed, that file size will almost always change between the 1 byte
placeholder and the hydrated file. Only when using the CfAPI on Windows
this won't be the case since because it will expose the original size
even for placeholders.
Also worth noting: the suffix backend didn't hit that case since the
filename changes (with suffix for placeholders, without for hydrated
files).
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Ideally this will end up being the backend we use for both Linux and
macOS but that will require work with desktop environments on the Linux
side and to reverse engineering at least on xattr value on macOS.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
There's been a confusion between the chunk number and the chunk
offset leading to corruptions... Let's pass the proper offset to
the UploadDevice again.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
MSVC having so useless error messages it didn't quite point to the root
cause of the issue... it turns out that through the maze of macros
defined in the windows API, there's one which impacted the function
pointer definition of CfCloseHandle which would then not convert to
FileHandle::Deleter as expected. So I end up wrapping it in a lambda to
help... luckily this kind of lambdas decay into a simple function
pointer so there's likely no overhead it's just to coerce the compiler
into doing the right thing.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
For some reason MSVC manages to deduce the right constructor in Win64
mode but not in Win32 mode. So let's be more explicit about what we
return.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise this would attempt to download the file everytime we check the
direct editor for a given file which wouldn't be adequate. Would also
lead to a deadlock in our case since that would happen in the main
thread and implicit hydration is driven from there as well.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This comes with a test simulating an open request coming from another
process (although in our case it's really just a thread). The actual
hydration works as expected by cfapi, handling of encrypted files is for
now missing.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
For now this implements only the logic necessary to get a test suite
equivalent to the TestSyncVirtualFiles one to pass. It doesn't (yet)
honor request to fetch files from the system.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Shouldn't be translated.
Just checked https://en.wikipedia.org/wiki/HTTP_ETag and all available localized pages.
Signed-off-by: rakekniven <mark.ziegler@rakekniven.de>
We will have all the code in public anyway so it can just be compiled
in. Thus no need to go through the plugin loading dance. Replaced the
loading with factory functions. Kept mostly the same structure
otherwise.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
It felt odd to be able to control the encryption status in the settings
dialog but not the availability. Also availability was controllable on
the root, so let's make it widely available.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This got removed from the settings since in that case selective sync
isn't supported. Unfortunately that's also necessary to display them to
allow encrypting folders via the context menu.
So we display the subfolders again but in the case of VFS we disable the
ability to (un)check them. They just have an icon, a name and a context
menu.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise we would not display the E2EE message if the account was
connected before the creation of the settings dialog. This was likely
caused by the delayed creation of the settings dialog.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
If we use those encrypted propagation code paths, we already know from
the discovery phase (and thus the journal db) that the folders are
encrypted so no need to check again.
This will remove another expensive round trip with the server.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This step isn't necessary anymore, no one looks at ClientSideEncryption
for that information anyway.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We used the same approach than for the FolderStatusModel by getting the
is-encrypted property straight from the LSCOL job.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Thanks to the new discovery algorithm, we got all the freshest E2EE
information straight from the database so reuse it instead of going
through an in memory copy.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
It had a different path convention than all the other jobs, most likely
for legacy reasons because of the tight coupling it had to the settings
dialog.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
No need to look for a token on the outside we can just work properly by
keeping all the state encapsulated in the job.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Thanks to the new discovery algorithm we got both mangled and original
file names in the item so no need to go through the database for
nothing.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Now we pull the encrypted metadata during the discovery which is a
better approach than before. This shall remove the need for some of the
deep propfinds we have been using so far. It already simplifies the code
a bit for the download scenario.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We now enforce the use of QStringLiteral and friends in some places,
but that feel through the cracks for some of the Windows specific code.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We also don't have a version entry in the db if thne db is new.
As I don't expect regular updates from 1.5 this message can just be removed.
Fixes: #8004
[ fatal default ]:ASSERT: "last < rowCount(parent)" in file C:\_\17a9f6ae\qtbase-everywhere-src-5.12.9\src\corelib\itemmodels\qabstractitemmodel.cpp, line 2787
e1ca612c5d3087e02f6b7f8e454224e0b88e82ad stopped adding sub folders so we can return the actual size.
The OAuth authentication brings the broweser to the front, once thats done the wizard continues.
But the wizard ist now most probably hidden behind the browser
This code was actually not breaking most cookie handling by accident.
As the raw cookies where not split properly we added cookies with values like
"key: val; key2 = val2; key3 = val3"
When the code was corrected we overwrote the newer values in the jar with
the old ones from a request.
allexzander