Cannot delete tag from moved card to cloned board

[kapitan-iglu]

Describe the bug When moving card from one board to cloned one, original tags cannot be removed anymore.

To Reproduce Steps to reproduce the behavior:

1. Create tag X in existing board A.
2. Assign tag X to card C on board A.
3. Clone board A (new board named A (copy) is created with cloned tag list and without any cards as exected).
4. Move card C to cloned board A (copy).
5. Result:
   • Old tag X is preserved on moved card C.
   • I'm able to assign same tag X to this card again, so there are two X tags.
   • I'm unable to remove original tag X (assigned in step 2)

Expected behavior Some way to remove old tag X after card was moved to another board.

Client details:

• Browser: Chromium 87.0.4280.141
• Device: desktop

Server details

Operating system: Debian

Web server: Apache 2.4

Database: MySQL 5.5.62

PHP version: 7.3

Nextcloud version: 18.0.12

[aproposnix]

If I understand this correctly, the workaround is to remove the tag on mobile (Not on desktop). That's how I do it.

EDIT: But let's see what the devs say :) Don't count on a random stranger with advice :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[monolied]

I have a very similar issue. In my case, the tag "To review" (semantically the same as "Zur Prüfung") was created with a different language setting, which makes it easier to spot. The behavior, however, is identical; at least I believe so. In the screenshot, you can also see that "To review" isn't offered for unselecting in the card's drop down list and therefore can not be removed. Somewhat remarkable is also, that the tags don't follow any changes of the language setting, though they must have done at one point. It could be a relative of #2826. #2826 also shows some interesting table contents. Would be great to know how the tables are organized and structured, so one could use some SQL to get rid of that (or fubar the database).

[monolied]

OK, I dug into that a bit. Problem is following I guess. # 155 is the affected card.

nextcloud=# select * from oc_deck_assigned_labels where card_id=155;
 id  | label_id | card_id
-----+----------+---------
 307 |       18 |     155

nextcloud=# select id, title, board_id from oc_deck_labels where id = 18;
 id |   title   | board_id
----+-----------+----------
 18 | To review |        5

This is the tag 18, dangling from card 155. It's also associated with board 5. There is no direct relation of card with board (I believe) but the card is associated with a stack, in this case stack_id # 7.

nextcloud=# select id, stack_id from oc_deck_cards where id = 155;
 id  | stack_id
-----+----------
 155 |        7

However, stack # 7 is associated with board # 2, not board 5:

nextcloud=# select id, board_id from oc_deck_stacks where id = 7;
 id | board_id
----+----------
  7 |        2

So while the label is shown in the card because of card_id and label_id in oc_deck_assigned_labels, it isn't offered in the dropdown since it's not in the stack, which does make sense - you don't want to have all existing tags in that list. However, this relation must be respected - or dropped - when there is migration / cloning.

With this in mind, it probably has nothing to do with #2826 , since there is a pkey on oc_deck_labels.id . Still, that issue was very helpful in getting me on track with regard to the database structure.

[eliasp]

I can confirm this using

• Nextcloud 23.0.1
• Deck 1.6.0

Created a card in one Board, assigned amongst others the default tag "Action beeded". Moved the card to another Board, tried to remove "Action needed", but ended up in this scenario - not being able to remove it.

[wanardin]

This error still persists in February 2024, using Nextcloud version 28.0.2 and Deck version 1.12.2

[monolied]

Given the structure of the tables and some design decisions (like making oc_deck_labels.id, oc_deck_assigned_labels.id etc a sequence), and the fact that these relations get broken up with a card move, and the activity on this issue so far... I wouldn't count on a fix soon. The whole process of creating and managing labels willl have to be redesigned. Or the move has to recreate the label but do a lot of checks ... Given that, here are some fixes, which help you identify and get rid of dangling labels.

All are working with postgres, you might have to adapt them for a different db.

Following will give you a list of cards with their unmanageable labels:

select distinct c.id, c.title, l.title from
oc_deck_cards c, oc_deck_labels l
where (c.id, l.id) in (
        select card_id, label_id from oc_deck_assigned_labels del
        where label_id not in (
        select l.id from oc_deck_labels l,
                   oc_deck_stacks s, oc_deck_cards c
        where l.board_id = s.board_id
        and   s.id = c.stack_id
        and   c.id = del.card_id)
) order by c.id
;

If you want to delete labels, you might want to add appropriate labels from the list of manageable ones to the affected cards before the now attached ones are lost. This might give you double labels for now, but that's fine, because we delete the locked ones now:

delete from oc_deck_assigned_labels del
where label_id not in (
select l.id from oc_deck_labels l,
       oc_deck_stacks s, oc_deck_cards c
where l.board_id = s.board_id
and   s.id = c.stack_id
and   c.id = del.card_id)
and   del.card_id = <id>
;

This example only changes a single card, as a safety. It limits with the and del.card_id = <id>, with <id> being one of the numerical ids from the first query result. If you want to delete all stuck labels at once, you remove the and del.card_id = <id> part between ) and ;. Reload of the page should show you only the manageable labels now. No restart required.

And, since this is only tested by me, you should lock nextcloud in maintenance mode, make a backup of oc_deck_assigned_labels before you try this, use transactions, and I'd really recommend to do it card for card, if you can afford the time. (SQL does the job, but you're free to improve it, ofc... I'm a bit rusty with that.)

[monolied]

Come to think of it, another (manual) workaround would be: Move the card back, remove all labels, move it to where it's supposed to be. That being said, I also have a revision of the first query giving more information about the dangling label, making it easier to find it by board and stack title:

select c.id, c.title card, s.title stack, b.title board, l.title label from
oc_deck_cards c, oc_deck_labels l, oc_deck_stacks s, oc_deck_boards b
where (c.id, l.id) in (
        select card_id, label_id from oc_deck_assigned_labels del
        where label_id not in (
        select l.id from oc_deck_labels l,
                   oc_deck_stacks s, oc_deck_cards c
        where l.board_id = s.board_id
        and   s.id = c.stack_id
        and   c.id = del.card_id)
) and s.id = c.stack_id
  and s.board_id = b.id
 order by c.id
;

[grnd-alt]

this should be resolved by #6257