Add time spent mapping on user profile

[sunidhiraheja]

Fixes #1082

Ready for review

[bgirardot]

Cool! Can't wait to test it.

[ethan-nelson]

Hi @sunidhiraheja, thanks! I tried running this out of the box and ran into an error:

--------------------------------------------------------------------------------
CRITICAL in stats_api [/home/enelson/tasking-manager/server/api/stats_api.py:180]:
User GET - unhandled error: String does not contain a date.
--------------------------------------------------------------------------------

This may be because we only recently added the action text duration in #1064, so for older tasks there is nothing that can be calculated. Edit: okay, apologies, after looking closer this was an incorrect explanation. I will look further to see if I can find the cause. In any case, curious to still get thoughts on the below.

Additionally, this error took about 30 seconds of postgres processing to come up--at least on my local machine--so it required some computation. Considering those points, I'm wondering if we should reconsider the implementation of this. Users that have hundreds or thousands of task events (locks, unlocks, etc) will put a pretty heavy load on the database when the time spent is recalculated on every profile load.

What if instead we kept a running count of time that tasks are locked for mapping in the user column? Then in a given task event of unlocking/marked mapped/marked validated, the delta time would be added to the total time column at that stage. Finally, the stats endpoint would then query and display that total time column.

This would also require an initial calculation of all the check out times in some form (either a migration script or a function). It would need to be coordinated to minimize downtime or database load, but is not unfeasible I don't think.

What are your thoughts. Does this seem reasonable? @bgirardot or others, any thoughts?

[ethan-nelson]

Two amendments to the above:

Regarding the error: diving a little further, it looks like mapping durations were not calculated during migration (

tasking-manager/devops/tm2-pg-migration/migrationscripts.sql

Line 181 in fe0b152

-- not attempting to calculate the length of time task locked

). What we could do for the time being is focus on time calculations only based on TM3 mapping (perhaps adding TM3 only or something on the display). So we could add a try or if clause to ignore cases where there's a none occurring or an error thrown in the loop that sums them.

Regarding the timing: it appears the major blocker in timing was the user's project contribution listing and not this one (which really needs review in #1144), so I think the load caused by the stats will not be bad.

Bottom line: if you can make the changes adding TM3 only to the text and adding an if action_text is not None block to the time addition, this should be good to go!

[ethan-nelson]

Thanks--I will take a look again very soon.

[ethan-nelson]

Thank you again @sunidhiraheja for this feature addition!!