feat: add card dependencies#7879
Conversation
|
🐢 Performance warning. |
94af509 to
a617e7d
Compare
|
🐢 Performance warning. |
a617e7d to
2372fa3
Compare
|
🐢 Performance warning. |
2372fa3 to
20b3b3a
Compare
|
🐢 Performance warning. |
|
Awesome to see some movement on this. |
|
Recording video: demo.mp4 |
Signed-off-by: Luka Trovic <luka@nextcloud.com>
20b3b3a to
b40148b
Compare
|
🐢 Performance warning. |
grnd-alt
left a comment
There was a problem hiding this comment.
didn't review everything yet. It basically works, but looking at the comment in the migration step, I think this part needs a rework.
| if ($boardId) { | ||
| $board = $this->boardService->find($boardId, false); | ||
| if ($board->getExternalId()) { | ||
| // External board support can be added later if needed |
There was a problem hiding this comment.
if we don't implement it yet we should throw a not implement exception here
| $schema = $schemaClosure(); | ||
|
|
||
| if ($schema->hasTable('deck_cards')) { | ||
| $table = $schema->getTable('deck_cards'); |
There was a problem hiding this comment.
I'm curios about the thought process of storing related cards as json field. Why not have it as an actual db relation so we can have both depends on and required by displayed.
Storing it this way also removes the ability to auto-delete relations, right now if a card is deleted the depending json will never be changed and the frontend will keep trying to retrieve that card, while the json only keeps growing.
Summary
Introduces the concept of "dependent cards", allowing users to assign and remove dependencies between cards. The implementation includes backend support, API routes, database migration, and frontend UI integration for managing card dependencies.
Checklist