I came across something interesting today, working on a project that is supposed to automatically archive all cards on a Trello board that are in the “Completed” column and are more than two weeks old.
This should have been really easy. Use the /1/lists/<list_id>/cards GET request to get all of the cards on the list then check to see if the dateLastActivity of the card was more than two weeks ago. If so, make a /1/cards/<card_id>/closed PUT reqest with the value set to true to close the card (touching on one of my favorite annoyances with the Trello API, that the interface uses the term “archived” but the API uses “closed” with no explanation).
What I was seeing, though, was that every card in that list was showing a dateLastActivity of the exact same second (milliseconds apart), at a time when it was highly unlikely that any of the cards (let alone all of them) were actually being touched.
My conclusion is that there’s something that Trello itself does that can cause dateLastActivity to be updated. I don’t have anything to back that up but it seems most logical.
What that means, though, is that dateLastActivity is unreliable.
The option I’m going with instead is to make an extra request for each card, using GET /1/cards/<card_id>/actions with filter set to all and limit set to 1 to get the most recent action for each card, then taking the date of that as a true indicator of last activity. It means an extra call for each card, which is awful but seemingly can’t be helped.
Taking that a step further for this specific case, the date comparison can be handled at the API level rather than in the script. Instead of requesting the just the latest action I can request the latest action after my date cutoff using the since parameter. If I get any actions back at all, the card has been touched and shouldn’t be archived.
I have no idea why Trello would make dateLastActivity unreliable but it’s extra calls to their infrastructure to make up for it so maybe they’ll do something about it in the future.
