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>
