Wrong time

[grapheine]

Hi, We work with a trello column « Tâches en cours". As soon as a task is in progress, we drag the card into the column in progress. These cards can be manipulated by several people in the team.

When we look at the time spent, we see some strange calculations. Here are some screenshots detailing our problem

for example this card, indicates a time of 98h (VS 19h for 3T of Bsode)

We can see that Emma would have activated the card for 91 hours by dragging it into the "Tasks in progress" column But according to the movements of the card Camille would have removed the card after a few hours (and not after 91h!).

Another example :

In this other example, gaspard puts the card in at 15:07, and then takes the card out at 18:37. However, in the calculation your tool counts the time until 9:10 am the next day.

Don't you use the card movement records to calculate the time taken?

Thank you very much for your help on these bugs

[grapheine]

Another example... On friday 14, emma drop the card on "Tâches en cours" at 09:50... but your timer start à 10h15. On thuesay 18, Emma drop the card into "Tâches en cours" for 25 minutes, but your timer see 0 min.

????

[grapheine]

other example :

You can see Emma putting the card on "Tâches en cours" the 6 oct at 14:10 and Nicolas removing the card at 18:45, but the time count is 91h ???

[danniehansen]

Hi @grapheine,

Sorry for the delay in my answer. I'll be adding this to my backlog of issues that will be looked into this weekend.

For the time being. You could disable the automatic start / stop functionality and instruct your users to manually start / stop the timer.

Then once resolved they should be able to operate again as usual.

Thank for the patience.

[danniehansen]

@grapheine A follow up question and a clarification. You asked if we're using the movements on the card for the tracking. This we're not as tracking is perfectly possible without actually moving the card. One can just open a card and track on it, even if it hasn't moved. So there is every chance that a person has started the timer manually, after moving it away from your in progress column. One of the other reasons for us not doing this is that it's not accessible through the client-side library for powerups.

In order to listen on movements and who did what movement. Then this would have to be accessed through the API on a server-side. Since we're primarily client-side, this wasn't an option.

To my question. Do you know if the examples you gave, if anyone of them could have user the mobile-app to move the card away? Since mobile app doesn't support community power-ups, Activity timer wont recognize these movements.

Another thing i would like to point out is that there is no such thing as a movement event in Trello client-side. This makes it impossible to recognize card movements without guessing. The way that we "guess" movements are to have a timer running on the board for every card. When i can see a card list id doesn't match the previous list id. Then i assume a movement has been made.

Because of this, it's to be expected that card movement listeners isn't 100% accurate. However, I've worked with a team of 5 for over a year using this plugin and I never had such issues as mentioned here.

I'll be looking into this, this weekend. But I'm fairly sure this comes down to a few things:

1. People being able to start/stop timers without actually moving them.
2. Connectivity that causes the meta-data for card not to save.
3. Internal issues in Trello with card refresh timers not working accurately, causing our internal timers not to recognize card movement.

I'll try and give you a clearer answer before the weekend is over. But it is hard for me to say since there is many pitfalls.

[danniehansen]

@grapheine I've spent a great deal of time today investigating this. Unfortunately, I've been unable to find any concrete items in the source-code that could directly contribute towards this issue.

However, as explained in my previous reply. I think this may play a huge tole in this occurring. We transparent Trello badge's on the board to approximate card movements. This is automatically updating every minute, or most commonly when items are to be updated. On a board with a lot of other powerups, or large amounts of cards - this process could be extremely slow and error prone.

Similairly, the way that we detect who moved a card into a column is done through a webhook from Trello -> Activity timer. This webhook we've seen can sometimes be delayed and takes time to reach our backend. Once it reaches our backend it'll send a message to the client that on next tick it should start the timer for a specific card.

The issue with the above is that if user closes the window, or navigates to a separate tab while it's still awaiting the start of the card from the backend. Then chances are high that user doesn't get their timer activated, and/or ended before they come back.

Unfortunately, there isn't much we can do about this. Seeing as Trello doesn't offer any support for client-side listening on movements and seeing who moves. Then we have to do this kind of wizardry to approximate it. Which, can in various circumstances lead to improper results.

I'm sorry i don't have a better answer for you at this time. My best suggestion would be to communicate to your team to keep an eye on the red badge. So when moving it into in progress, wait for the red badge to appear & when moving out of in progress, then wait for it to disappear. If they do this, then they're at the very least making sure they're not proceeding until timer is active or deactivated. They'll also then be able to react in case it doesn't do it automatically and adjust the state of it by opening the card and start/stop the timer.

I'm going to leave this issue to see if more information arise. I also want to keep this at my forefront when i make further optimizations to the plugin, to see if i can better this movement detection.

[grapheine]

Salut @danniehansen

Thank you for looking for a solution. Until now we were using the 3T power-up from bsode. The latter, according to me, was just reading the activity of a card to deduce the time.

If I understand your message correctly, it seems that your system does not work like that.

For your information, our team is composed of 14 people. And our board is filled with several hundred cards. Can this have an impact on the slowness and errors?

We will follow your advice by observing the "little alarm clock", to check if its color changes when we drag a card in the "in progress" column.

According to our tests yesterday, it works in 90% of the cases, but it still happens that a collaborator drags the card in the "in progress" column without triggering the counter. It was a colleague, on another computer, who was forced to swipe the card for him. Not very practical.

To be continued.

[grapheine]

Here is an overview of the number of cards on the trello board. Can a large number of cards have an impact on the performance of your tool?

[danniehansen]

@grapheine Interesting regarding that other powerup which you mention. What they're most likely doing is reading this information off of their API & not through their existing client-side libraries. Doing this would require extensive re-work and also require users to up-front grant access to the API when setting up the power-up.

It may be that this power-up uses some undocumented functionality that I'm unaware of. I'll try to see if I can peak in their source-code to understand exactly how they're doing it.

Regarding the amount of cards. This could indeed be one of the reasons why this may be happening. A lot of cards can cause issues with the Trello badge update mechanism. This I've seen before. I'll try to use one of my old boards with large sum of cards to see if I can provoke the same behavior.

I will get back to you with my findings on both items.

[danniehansen]

@grapheine I've been looking at the source-code of 3T powerup and found that they are in fact doing everything server-side. Activity timer is built primarily using Trello's existing client-side data storage and capabilities for detecting card movement, storing card time etc. This naturally puts some limitations on what is possible for us seeing as we're limited by what is happening client side.

I've attempted to provoke the issue you're describing on large boards that i have at my disposal. And on neither boards that I'm able to view could i provoke this. The worst i found was a slight delay on ~5-10 seconds for the timer to kick-in and start. But it is to be noted that these 5-10 seconds can be crucial. Because Activity timer is client-side, then if user was to swap away during this wait time of 5-10 seconds. Then this could cause Activity timer first to see the action when they swap back to the tab/browser again afterwards.

I don't see a solution to this problem unless Activity timer is rearchitected to be fully server-side for the tracking. This is in the plans, but it's quite far out. Infrastructure is expensive and would require me to put much more money up front than I'm doing now. So before this can see the light of day i would been to have a stable pro subscription base that can cover the infrastructure cost. Until then, we'll have to deal with any such quirks as it makes the plugin sustainable :)

[danniehansen]

Closing, rearchitecting Activity timer will not be a viable solution. We will have to live with any such delays at this current time.