[REQUEST] Get list of N latest tracked items

[jbriales]

With the /api/times endpoint we can get a bunch of times, but only for known ids.

Would it be possible to query for the stack of N most recently tracked items as well?

If say I was tracking a bunch of tasks in the mobile app and then came back to my desktop station, I'd like to be able to query for all recently tracked tasks so that I can double-check correctness and update as needed my local tasks only for those tasks that have been recently active in the tracking server.

[amazingmarvin]

I don't have a field for lastUpdatedAt in this "table". And times are stored in an array. So either I'd have to fetch everything for this user and sort it by the last item in the array (expensive) or else add an extra index (high effort). Probably it would make more sense to add this functionality on the client as "sort by last tracked" rather than add it to the API. Does that cover your use case or are you working outside the Marvin desktop client?

[jbriales]

Thanks for the detailed response!
The use case here was more on the side of double-checking correctness and ensuring consistency of the locally stored tracked times in my own client (outside the Marvin desktop), after doing tracking from mobile apps.

But if there is no easy way to enable this from the server side, then it's fine. I will find some other workaround for my use case.
Thanks!

[jbriales]

Thinking about a potential workaround:

My main issue is about making sure my Marvin client keeps a correct copy of the tracked times in the server,
as I do 90% of my work with Marvin with this client, and the other 10% from the mobile app.
So that 10% done from mobile will not be properly reflected in my client (not Marvin desktop).

In a brute-force manner, I could query from the server the source of truth whenever I'm going to do some queries around tracked times. But I was afraid this would have two important downsides:

• Increasing my number of queries to the server, which might go over my quota.
• Introducing more overhead and delays in my UI.

That said, I could imagine a way to go would be keeping an additional field in the task doc, sth like trackedFrom: [...] where we would add some kind of unique per-client identifier whenever tracking was done from a client (for the first time).
I.e. if you start tracking from mobile, you'd add that mobile client identifier to the list.
Then when I want to refresh times for recent tasks in my local client, I could query the server only for those tasks that were ever tracked from outside my local server (a much smaller nr than my overall nr of tasks).
This approach might scale well to having more than 2 clients (if there is more machines, or several mobile devices).

Any thoughts on that?

Otherwise, I'd be happy to learn more about how you approach keeping consistency of times in the desktop app nowadays.
In the past I've seen frequent bugs around visualization of times, that's why I was concerned with introducing some extra checks from my side.

[amazingmarvin]

Hey, sorry I haven't been checking these issues for a while! What about using:

POST /api/times
{
  "date": "2022-09-12",
  "timeZone": -120 // GMT+2
}
=>
["ABC", "XYZ", ...] // IDs of tasks tracked on that day

[amazingmarvin]

This, and a recent bug report about 500 errors when starting/stopping time tracking, has made me rethink time tracking data. Possibly the endpoint I mentioned above will stop working. On the plus side, it should fix the time tracking problems you've seen in Marvin. Possibly there will be a minor performance cost - will have to monitor that. Anyway, check it out on pre soon :) and let me know if you have questions.