[feature/kiteworks-build] Kiteworks Integration

[Matthias-Huehne-Kiteworks]

Description

This PR adds Kiteworks integration to the iOS ownCloud app.
The SDK was adopted to detect a Kiteworks server and proceed with the needed logic.

The iOS app got some adoption regarding sidebar items and not to show folder sizes (as it is not available on Kiteworks server).

Related Issue

Motivation and Context

How Has This Been Tested?

• login wih a Kiteworks (Test-)server URL
• login with an ownCloud server URL (to check if ownCloud login is still working)

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• Added an issue with details about all relevant changes in the iOS documentation repository.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• Added changelog files for the fixed issues in folder changelog/unreleased

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

✅ felix-schwarz
✅ hosy
❌ Matthias-Huehne-Kiteworks
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[felix-schwarz]

A new OCConnection is instantiated on purpose for each step calling this method, to always start at from a fresh slate. What problem does instantiating only one OCConnection and keeping it around solve?

[Matthias-Huehne-Kiteworks]

If I do not have this change I lose the server status in the setup process and I cannot access later the Kiteworks product.

[felix-schwarz]

Thanks. I see that in the SDK, you implement OCConnection.isKiteworksServer as

- (BOOL)isKiteworksServer
 {
     return (([((NSDictionary *)self.bookmark.userInfo[@"statusInfo"])[@"product"] isEqual:@"kiteworks"] || [self.product isEqualToString:@"kiteworks"]));
 }

which depends on the statusInfo (OCBookmarkUserInfoKeyStatusInfo) stored in the bookmark in -[OCConnection connectWithCompletionHandler:], which will only be called at the point where authentication is already set up. That info should also not get lost when not re-using the OCConnection, as it that info is stored in the OCBookmark that's being operated on during setup.

[Addition lateron: I only just saw that you're also using a new OCConnection.product property here, whose value will indeed vanish with the instance. However, instead of storing that value in the OCConnection.product (where it'll go away), only to then check it later, please consider checking it right for equality with kiteworks right away - and if it is equal, store it as kiteworks capability as suggested below.]

A more stable and easier way to store that info would be using -[OCBookmark addCapability:] and -[OCBookmark hasCapability:], which is already used to mark a bookmark as supporting drives (spaces) and favorites. Here's how that looks for drive support:

- (BOOL)useDriveAPI
{
	return (self.capabilities.spacesEnabled.boolValue || [self.bookmark hasCapability:OCBookmarkCapabilityDrives]);
}

A benefit is that you can use that OCConnection.isKiteworksServer, but also directly with OCBookmark anywhere via f.ex.[bookmark hasCapability:OCBookmarkCapabilityKiteworks].

At any rate, persisting and re-using the OCConnection instance should not be needed as

• the info should be stored in the OCBookmark - from where a new OCConnection instance can also fetch it
• this is not how OCConnection was used until now, so using it like this is uncharted territory and might have unwanted side-effects

[felix-schwarz]

Thanks. I see that in the SDK, you implement OCConnection.isKiteworksServer as

- (BOOL)isKiteworksServer
 {
     return (([((NSDictionary *)self.bookmark.userInfo[@"statusInfo"])[@"product"] isEqual:@"kiteworks"] || [self.product isEqualToString:@"kiteworks"]));
 }

which depends on the statusInfo (OCBookmarkUserInfoKeyStatusInfo) stored in the bookmark in -[OCConnection connectWithCompletionHandler:], which will only be called at the point where authentication is already set up. That info should also not get lost when not re-using the OCConnection, as it that info is stored in the OCBookmark that's being operated on during setup.

[Addition lateron: I only just saw that you're also using a new OCConnection.product property here, whose value will indeed vanish with the instance. However, instead of storing that value in the OCConnection.product (where it'll go away), only to then check it later, please consider checking it right for equality with kiteworks right away - and if it is equal, store it as kiteworks capability as suggested below.]

A more stable and easier way to store that info would be using -[OCBookmark addCapability:] and -[OCBookmark hasCapability:], which is already used to mark a bookmark as supporting drives (spaces) and favorites. Here's how that looks for drive support:

- (BOOL)useDriveAPI
{
	return (self.capabilities.spacesEnabled.boolValue || [self.bookmark hasCapability:OCBookmarkCapabilityDrives]);
}

A benefit is that you can use that OCConnection.isKiteworksServer, but also directly with OCBookmark anywhere via f.ex.[bookmark hasCapability:OCBookmarkCapabilityKiteworks].

At any rate, persisting and re-using the OCConnection instance should not be needed as

• the info should be stored in the OCBookmark - from where a new OCConnection instance can also fetch it
• this is not how OCConnection was used until now, so using it like this is uncharted territory and might have unwanted side-effects