Rename account with jtx collection: IllegalArgumentException

[rfc2822]

During rename:

Couldn't propagate new account name to tasks provider
java.lang.IllegalArgumentException: Currently only Syncadapters are supported. Uri: (content://at.techbee.jtx.provider/tasks)
	at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:185)
	at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:155)
	at android.content.ContentProviderProxy.update(ContentProviderNative.java:685)
	at android.content.ContentProviderClient.update(ContentProviderClient.java:417)
	at android.content.ContentProviderClient.update(ContentProviderClient.java:406)
	at at.bitfire.davdroid.resource.LocalTaskList$Companion.onRenameAccount(LocalTaskList.kt:40)
	at at.bitfire.davdroid.repository.AccountRepository.rename(AccountRepository.kt:259)
	at at.bitfire.davdroid.repository.AccountRepository$rename$1.invokeSuspend(Unknown Source:15)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:101)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:589)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:832)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:720)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:707)

Steps to reproduce:

1. Use DAVx5 with jtx Board, sync a collection.
2. Rename the account and watch the logs.

Possible reason: rename accounts always expects an OpenTasks task app (and not jtx Board).

Further info: Also LocalTaskList.onRenameAccount should be moved to LocalTaskListStore.updateAccount.

[rfc2822]

I think the problem is that LocalTaskList.onRenameAccount always expects an OpenTasks-compatible task list, even if jtx Board is the current app.

We should probably call something like LocalTaskListStore.updateAccount(), which then does the correct thing according to the task list provider instead.

[ArnyminerZ]

Yup, reproduced correctly as stated:

Logs

Couldn't propagate new account name to tasks provider
java.lang.IllegalArgumentException: Currently only Syncadapters are supported. Uri: (content://at.techbee.jtx.provider/tasks)
    at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:172)
    at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:142)
    at android.content.ContentProviderProxy.update(ContentProviderNative.java:653)
    at android.content.ContentProviderClient.update(ContentProviderClient.java:417)
    at android.content.ContentProviderClient.update(ContentProviderClient.java:406)
    at at.bitfire.davdroid.resource.LocalTaskList$Companion.onRenameAccount(LocalTaskList.kt:40)
    at at.bitfire.davdroid.repository.AccountRepository.rename(AccountRepository.kt:259)
    at at.bitfire.davdroid.repository.AccountRepository$rename$1.invokeSuspend(Unknown Source:15)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:101)
    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:589)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:832)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:720)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:707)

[ArnyminerZ]

Okay, so after tumbling around for quite longer than I expected, I guess that the problem is that OpenTasks-compatible apps use the content provider as .../tasks, and Jtx uses (I think) .../collections:

https://github.com/TechbeeAT/jtxBoard/blob/develop/app/src/main/java/at/techbee/jtx/SyncContentProvider.kt#L140C42-L140C52

which is what holds the account:

https://github.com/TechbeeAT/jtxBoard/blob/a9c4c727e414a08b1d669236ac2675cb1c6f4342/app/src/main/java/at/techbee/jtx/database/ICalCollection.kt#L138-L144

Then the thing would be to check whether the provider is jtx board, and use /collections or use /tasks otherwise. Is this correct?

I've tried doing this, and it's still failing with "Currently only Syncadapters are supported". My question is also whether this is a problem of our own, or it's caused by Android, and we are simply trying to do something that is not supported.

[rfc2822]

Okay, so after tumbling around for quite longer than I expected, I guess that the problem is that OpenTasks-compatible apps use the content provider as .../tasks, and Jtx uses (I think) .../collections:

https://github.com/TechbeeAT/jtxBoard/blob/develop/app/src/main/java/at/techbee/jtx/SyncContentProvider.kt#L140C42-L140C52

which is what holds the account:

https://github.com/TechbeeAT/jtxBoard/blob/a9c4c727e414a08b1d669236ac2675cb1c6f4342/app/src/main/java/at/techbee/jtx/database/ICalCollection.kt#L138-L144

Yes, during rename, we want to change the account.

1. jtx Board has the ACCOUNT_NAME in Collection – the jtx Board database should however not be relevant (or is only indirectly). The relevant lines are in JtxContract:

https://github.com/TechbeeAT/jtxBoard/blob/a9c4c727e414a08b1d669236ac2675cb1c6f4342/app/src/main/java/at/techbee/jtx/contract/JtxContract.kt#L1189-L1199

So if we want to update the account name in jtx Board, we have to update the Collections using the correct Collections.CONTENT_URI "as sync adapter", see the other collection updates in ical4android.

It's however possible that jtx Board refuses to change the account when we request it. In this case, we would have to open a feature request for jtx Board. But even then it shouldn't try the wrong (OpenTasks) URI for jtx Board.

2. Tasks.org / OpenTasks on the other side use the method that's currently used.

Then the thing would be to check whether the provider is jtx board, and use /collections or use /tasks otherwise. Is this correct?

Yes, but I think the check shouldn't be in onRename. Instead, we should probably call something like LocalTaskListStore.updateAccount() (with LocalTaskListStore according to the current task provider type, so LocalJtxCollectionStore for jtx Board and LocalTaskListStore for the others), which then does the correct thing according to its task list provider instead.