Move entire list to a different board

[l-mb]

Is your feature request related to a problem? Please describe.

Sometimes, complexity grows.

While it is easy enough to move cards between new and old lists on the same board, once I want to break to declutter a given board and dedicate a new one to a subject, there is no way to move cards in bulk to a new board.

I can only move cards one by one, by every time selecting the new board and list, which is very cumbersome and it's in fact faster for me to just have both boards open and retype the cards ... (Unless they have more context than just the title, of course.)

Describe the solution you'd like

When I click on the ... for a list, I'd like there to be an option to move (or copy) the entire list to a different board.

Describe alternatives you've considered

Alternatively, if I could select multiple cards (via ctrl-click like in other applications, maybe?), I could then do a bulk-move. But I prefer the ability to move an entire list.

[RSC-FSD]

I have the same problem. For me, the solution must also include the movement of the assigned, uploaded documents.

[varac]

Sometimes, complexity grows.

This is an adequate summary for mt life :rofl: Looking forward for this feature!

[tomatic]

A workaround for the technically inclined:

Lists (or stacks) are stored in the database in the oc_deck_stacks table and the column board_id holds the id of the board they're assigned to, which you can also see in the URL of a board, e. g. /apps/deck/#/board/23.

If you change the board_id of the list you want to move to the ID of the target board, the stack will be "moved" to that board. Tried it and I didn't notice any adverse effects or inconsistencies.

[psttf]

A workaround for the technically inclined:

This can also be done using the REST API which may be easier to access than the database. The thing is that boardId value can be updated with the update stack request (it is not obvious from the docs):

curl -i -u <USER>:<PASSWORD> -X PUT -H 'Content-Type: application/json' \
  -H "OCS-APIRequest: true" \
  'https://nextcloud.example.org/index.php/apps/deck/api/v1.0/boards/<OLD_BOARD_ID>/stacks/<STACK_ID>' \
  -d '{"boardId":<NEW_BOARD_ID>,"title":"<STACK_TITLE>","order":<STACK_ORDER>}'

[philffm]

Second this, would also really appreciate being able to copy cards across decks. Came across this approach here where every week has a card, then the entire card gets archived to done: https://levels.io/how-i-build-my-minimum-viable-products/

The API workaround seems interesting as well - can imagine some automations to resolve it, such as

• each week create a new deck for the according week
• if after e.g 3 weeks it has not moved, move to archive deck

Will also review the code to maybe fix it myself / add a PR

[MacLemon]

This can also be done using the REST API which may be easier to access than the database. The thing is that boardId value can be updated with the update stack request (it is not obvious from the docs):

curl -i -u <USER>:<PASSWORD> -X PUT -H 'Content-Type: application/json' \
  -H "OCS-APIRequest: true" \
  'https://nextcloud.example.org/index.php/apps/deck/api/v1.0/boards/<OLD_BOARD_ID>/stacks/<STACK_ID>' \
  -d '{"boardId":<NEW_BOARD_ID>,"title":"<STACK_TITLE>","order":<STACK_ORDER>}'

Sadly, this does not work for me. The documentation for PUT /boards/{boardId}/stacks/{stackId} - Update stack details doesn't accept "boardId":<NEW_BOARD_ID> as JSON payload. Nextcloud 31 also simply ignores the boardID and transparently keeps the old boardID, but renames the Stack accordingly and also reorders it. I'm receiving a 200 with or without a new boardID.

I've checked version 1.0, 1.1 of the API and none of them support “renaming” a stack to a different board as stated by the documentation.

If I'm missing something here, please add where you got this info from, because for me, it neither matches the documentation nor the actual behaviour of Nextcloud 31.

I'd love being able to move whole stacks at once, via API (and GUI). With Nextcloud 31 this is not possible with either in my experience.