Would it be possible for you to enable deletion of lists?
In the PowerUp, I am working on, I create an axillary list for moving and sorting cards, before they are distributed to respective lists. After the job is done, the list should, of course, be removed. I consider it a bad practice to just archive it, since it would be messing up users’ overview of their archived items - not exactly a seamless experience that I am hoping for.
The only solution that I found is to create a temporary board, move the list there and then remove the board, but I consider it a very inelegant and error-prone solution.
At the moment, we can delete cards and boards, but not the lists. Which I consider a bit odd. Allowing us to delete lists as well would not only be a helpful, but also a logical step.
Can you extend your API with the ability to delete lists?
Thank you for the feedback. The explanation seems reasonable. Still, I think that there is a place for a middle ground:
How about allowing deletion of empty lists (even if only via API)?
Another solution would be a ‘auxiliary list’, that could be used exclusively for data manipulation (such as moving many cards across boards) and would be open for removal when operation is finished successfully, or stay put, if errors popped up.
Both solutions would give us, developers, more freedom and thus enable us to provide more seamless experience to our user, while keeping them safe from accidental card deletion.
Can you provide more details on what you’re doing? For example, why do you need to create this list and add cards to it to do sorting? Could you do the sorting within your application logic instead?
I agree: The sorting can be done in the logic alone. It’s the moving of cards to a different board, especially when you want to preserve their order, that is problematic.
Example: You want to move top 20 cards from List 1 on board A, to List 2 on board B, while keeping their order as is.
Aha. Only because I don’t see any platform changes here anytime soon, could you move the cards one by one from the source list to the target list, in reverse order so that the end result is they are in the same order, but all at the top of the target list?
This could work. The sticking point is the moving of many cards across boards. If I do it without a ‘temporary’ list, I could potentially be running into a ‘LOCK_TAKEN_ERROR’.
Moving, potentially, tens of cards in a sequence can take a long time (even over a minute), hence I am offering the users an option to do it fast, in cases where order is of no importance. This option utilizes Promise.all(). There, the risk of running into ‘LOCK_TAKEN_ERROR’ is quite high if no ‘temporary list’ is used.
I assume that with sequential moving, the risk would be lower, but still present.
As far as I remember, dealing with this error with a re-try is quite difficult, since the ‘lock’ seems to be holding for quite a while, which could potentially make the operation very time-consuming and unreliable.
‘LOCK_TAKEN_ERROR’ is not documented anywhere, so I prefer to avoid it altogether, rather than expose my users to an unreliable service.
Using a ‘temporary list’, allows me to use the /lists/{tempListId}/moveAllCards API, where this error seem not to be a problem.
Aha - yeah I can absolutely see that and why you want a clean list so you can use that API call. I think your best best is to do what you’re probably already doing by creating an archived list you can reuse like “__NAMEOFPOWERUP_Move_List” or something. I see where you are concerned about messing up users’ overview of their archived items, but it’s a small price to pay for what whatever useful feature your power-up provides. And honestly, while you and I will look at that archived list as an “eyesore,” the average user likely will never see it. And they couldn’t delete even if they wanted to.
Yes, the archive-able list, is my plan B, but I would prefer to avoid it. Users surprised me more than once with the way they use my Power-Up and Trello in general, so I don’t want to make to many assumptions.
As of right now, plan A seems to be the least bad option.
