WIP: Add Kanboard migrator #1607

jackymancs4 · 2023-09-28T11:02:42Z

jackymancs4 commented

2023-09-28 11:02:42 +00:00

First-time contributor

Hello,
I have a fairly big Kanboard instance which I'm trying to move to Vikunja. This PR is extremely WIP, but any good pointer is welcome.
If there no interest on it, let me know and I'll close it.

Technical Notes

Kanboard uses Jsonrpc 2.0 for the API, so I need to add library to properly handle that.
Kanboard does not support Oauth, so I guess I'll have no use for AuthURL (?)

Hello, I have a fairly big Kanboard instance which I'm trying to move to Vikunja. This PR is extremely WIP, but any good pointer is welcome. If there no interest on it, let me know and I'll close it. ### Technical Notes Kanboard uses Jsonrpc 2.0 for the API, so I need to add library to properly handle that. Kanboard does not support Oauth, so I guess I'll have no use for `AuthURL` (?) ### Links for reference https://kanboard.org/ https://github.com/kanboard/kanboard ### Links for Docs https://docs.kanboard.org/v1/api/authentication/ https://docs.kanboard.org/v1/api/project_procedures/#getallprojects https://docs.kanboard.org/v1/api/board_procedures/ ### Dependencies added https://github.com/ybbus/jsonrpc/tree/v2

jackymancs4 added 1 commit 2023-09-28 11:02:49 +00:00

continuous-integration/drone/pr Build is failing Details

ea72978dd2 Add boilerplate code

jackymancs4 added 1 commit 2023-09-28 15:59:30 +00:00

continuous-integration/drone/pr Build is failing Details

dd0cc8ec47 Remove all references to Trello

Allow insecure connections.

konrad commented

2023-09-29 16:22:07 +00:00

Hey there! Thanks for the PR.

Can we modify it so that it will either ask the user for the kanboard URL and token or accept a file export? (does Kanboard even support those?)

Right now this would tie the Vikunja instance to the kanboard instance configured. Allowing users to "bring their own" kanboard instance will require work in the frontend, but that's a tradeoff I'm willing to make in favor of a better ux.

Are the kanboard tokens scoped by user?

Hey there! Thanks for the PR. Can we modify it so that it will either ask the user for the kanboard URL and token or accept a file export? (does Kanboard even support those?) Right now this would tie the Vikunja instance to the kanboard instance configured. Allowing users to "bring their own" kanboard instance will require work in the frontend, but that's a tradeoff I'm willing to make in favor of a better ux. Are the kanboard tokens scoped by user?

jackymancs4 commented

2023-09-29 19:39:27 +00:00

First-time contributor

Let's see:

Can we modify it so that it will either ask the user for the kanboard URL and token

You mean like a payload on the "migrate" POST request containing the endpoint and key? I'm totally fine with it, but isn't it different from how client secrets of the other migrators (e.g MicrosoftTodo) are handled?

accept a file export? (does Kanboard even support those?)

I'm afraid not. The suggested solution I've read about on the forum is to dump the database, or do it by code. But I'd rather use the API.

Right now this would tie the Vikunja instance to the kanboard instance configured. Allowing users to "bring their own" kanboard instance will require work in the frontend, but that's a tradeoff I'm willing to make in favor of a better ux.

I'm happy to get a shot at the UI If I manage to get this landed. But since I only really need the API now, I would like for that to be a second step. Of course let me know if the frontend side is a requirement.

Are the kanboard tokens scoped by user?

They can be. Relevant docs: https://docs.kanboard.org/v1/api/authentication/
I'm using the application API as I'm aiming at an instance migrator (users and all), not just my user. I can see why this might not be the best approach, especially on your hosted service.

If you can point me in the right direction on the first point, I can fix the auth flow before beginning to work on the models.
Maybe a new Migrator interface like:

// Migrator is the basic migrator interface which is shared among all migrators
type ApiMigrator interface {
	MigratorName
	// Migrate is the interface used to migrate a user's tasks from another platform to vikunja.
	// The user object is the user who's tasks will be migrated. opts is a map containing data passed as payload for the request
	Migrate(user *user.User, opts map[string]string) error
}

?

BTW it goes without saying that I'm really loving Vikunja. Thank you!

Let's see: > Can we modify it so that it will either ask the user for the kanboard URL and token You mean like a payload on the "migrate" POST request containing the endpoint and key? I'm totally fine with it, but isn't it different from how client secrets of the other migrators (e.g MicrosoftTodo) are handled? > accept a file export? (does Kanboard even support those?) I'm afraid not. The suggested solution I've read about on the forum is to dump the database, or do it by code. But I'd rather use the API. > Right now this would tie the Vikunja instance to the kanboard instance configured. Allowing users to "bring their own" kanboard instance will require work in the frontend, but that's a tradeoff I'm willing to make in favor of a better ux. I'm happy to get a shot at the UI If I manage to get this landed. But since I only really need the API now, I would like for that to be a second step. Of course let me know if the frontend side is a requirement. > Are the kanboard tokens scoped by user? They can be. Relevant docs: https://docs.kanboard.org/v1/api/authentication/ I'm using the application API as I'm aiming at an instance migrator (users and all), not just my user. I can see why this might not be the best approach, especially on your hosted service. If you can point me in the right direction on the first point, I can fix the auth flow before beginning to work on the models. Maybe a new Migrator interface like: ```go // Migrator is the basic migrator interface which is shared among all migrators type ApiMigrator interface { MigratorName // Migrate is the interface used to migrate a user's tasks from another platform to vikunja. // The user object is the user who's tasks will be migrated. opts is a map containing data passed as payload for the request Migrate(user *user.User, opts map[string]string) error } ``` ? BTW it goes without saying that I'm really loving Vikunja. Thank you!

konrad commented

2023-10-04 16:00:46 +00:00

You mean like a payload on the "migrate" POST request containing the endpoint and key? I'm totally fine with it, but isn't it different from how client secrets of the other migrators (e.g MicrosoftTodo) are handled?

Yes, that's different from how the other migrators work, but Kanboard seems to be quite different in how one should use their api as well. Using the Kanboard API seems like the correct solution though.

But since I only really need the API now, I would like for that to be a second step. Of course let me know if the frontend side is a requirement.

If we go this route, the frontend would be a requirement. But it's totally fine to implement the API first and then do the frontend part.

Another option would be to build a separate tool which creates a Vikunja-readable dump from a Kanboard instance.

If you can point me in the right direction on the first point, I can fix the auth flow before beginning to work on the models.

I'd rather add the relevant fields to the new Migration struct you created. The struct will be automatically populated from the request data.

> You mean like a payload on the "migrate" POST request containing the endpoint and key? I'm totally fine with it, but isn't it different from how client secrets of the other migrators (e.g MicrosoftTodo) are handled? Yes, that's different from how the other migrators work, but Kanboard seems to be quite different in how one should use their api as well. Using the Kanboard API seems like the correct solution though. > But since I only really need the API now, I would like for that to be a second step. Of course let me know if the frontend side is a requirement. If we go this route, the frontend would be a requirement. But it's totally fine to implement the API first and then do the frontend part. Another option would be to build a separate tool which creates a Vikunja-readable dump from a Kanboard instance. > If you can point me in the right direction on the first point, I can fix the auth flow before beginning to work on the models. I'd rather add the relevant fields to the new `Migration` struct you created. The struct will be automatically populated from the request data.

jackymancs4 added 1 commit 2023-10-05 08:57:40 +00:00

continuous-integration/drone/pr Build is failing Details

1397c052b6 Update authentication flow as per request

jackymancs4 commented

2023-10-05 14:21:32 +00:00

First-time contributor

But it's totally fine to implement the API first and then do the frontend part.

Will do.

The struct will be automatically populated from the request data.

I missed the request binding feature. That's nice.

The authentication flow know works as per requirements. Tokens can now be user scoped.
If you confirm, I can go on and implement the models.

> But it's totally fine to implement the API first and then do the frontend part. Will do. > The struct will be automatically populated from the request data. I missed the request binding feature. That's nice. The authentication flow know works as per requirements. Tokens can now be user scoped. If you confirm, I can go on and implement the models.

konrad commented

2023-10-11 09:00:24 +00:00