Timesheet reports across multiple workspaces

[n7st]

Hi,

Testing under the development branch, timesheet reports seem to be on a per-workspace basis.

It would be useful to be able to run a daily report across multiple workspaces (for example for tracking time across multiple projects for one billable entity) or run a report on specific workspaces without switching to them individually.

Today, I have three active workspaces (split by project, chargeable to one company) with time spent on tickets logged under each one. To send my daily report, I had to tid stop and cycle through the workspaces running tid report on each one.

Example data:

% tid workspace ls
default
DPC00005 *
Support
DPC00032

% tid timesheet ls
+------------+---------+----------+
|    DATE    | ENTRIES | DURATION |
+------------+---------+----------+
| 2017-04-18 | 4       | 6h56m27s |
+------------+         +          +
| TOTAL      |         |          |
+------------+---------+----------+

The bash script below meets the feature request in a roundabout way (list the workspaces and find which one you're on at the moment, find your currently active check-in, loop through workspaces running a report on each and then resume your active check-in).

#!/usr/bin/env bash
set -euo pipefail;

WORKSPACES=$(tid workspace ls | awk '{ print $1 }');
ACTIVE=$(tid workspace ls | grep '*' | awk '{ print $1 }');
STATUS=$(tid status -f="{{.IsRunning}}");
TASK=$(tid status -f="{{.ShortHash}}");

if [[ $STATUS == "true" ]];
then
    echo "Stopping tid timer...";

    tid stop;
fi

for ws in ${WORKSPACES[@]};
do
    tid workspace switch $ws > /dev/null;
    report=$(tid report);

    if [[ "$report" != "report: No entries within the given time period" ]];
    then
        echo "

Project $ws
$report";
    fi
done

if [[ $STATUS == "true" ]];
then
    echo "Resuming tid timer (ShortHash $TASK on workspace $ACTIVE)...";

    tid workspace switch $ACTIVE;
    tid resume $TASK;
fi

Thanks, Mike

[seeruk]

This is an interesting one. I'd not really thought of workspaces being used like that! The idea I had was that they would be intentionally very separate to purposefully avoid being able to do this kind of thing. 😅

I do think this is a fair idea though. Relying on magic strings isn't very nice either, I think something Callum has changed may make that a little less magical though thankfully.

One thing that springs to mind is just having an extra option on the list commands for entries and timesheets, something like --workspace=<NAME> with a special choice of * or something that would fetch data from all workspaces. I think this should be doable, it might just need another factory method to get a gateway for each workspace bucket to facilitate that option. 🤔 Right now it just keeps the current bucket being used for the current workspace tucked away and hidden from the commands so they don't know about it.

Perhaps an intermediate solution would be to a) improve the scriptability of requesting the data for multiple timesheets by using exit codes instead of strings, and b) to then merge a helper script into the repository so that at least there is something in there that can be maintained along with Tid to do that job until something better in code comes along?

[n7st]

The idea I had was that they would be intentionally very separate to purposefully avoid being able to do this kind of thing.

I had wondered if I was misusing the workspaces a bit! The alternatives, I think, would be projects inside workspaces (which would be over complicating things), or an extra field available on the report for a project code or name.

Improving the scriptability is definitely a good intermediate solution and will probably prove useful elsewhere. Go's templating seems to be really handy for getting the exact content you need in the exact format so it lends itself really well to being scripted. When the exit code adjustment is integrated into Tid, I'm happy to submit a PR with an updated script.

[seeruk]

Alright, so the changes to make the tid exit with error code 1 are in now, on any kind of error / warning type thing. This should make the script a bit nicer and less brittle around the magic string area. Did you want to submit a PR for the script once you'd updated it?

[n7st]

Sure thing - I'll update it in the next few hours.