Export issue time tracking information

Resources

PM @victorwu

Docs blurb

In 9.0, we introduced the ability to export issues in CSV format. With this release, we are including the time estimate and time spent in the export as well, allowing you more flexibility in work and resource management for those use cases outside of GitLab.

Description

• Add time tracking information to the issue export functionality here: https://gitlab.com/gitlab-org/gitlab-ee/issues/1480.
• Per issue add:
  • Current time estimate. Call the field Time Estimate
  • Current time spent. Call the field Time Spent
  • The format of the two fields should be in seconds, with 5 decimal places in the CSV file.

Inspiration: https://marketplace.atlassian.com/plugins/is.origo.jira.tempo-plugin/cloud/overview

mentioned in issue #1271 (closed)

Has anyone tried TimeCamp with Gitlab? It integrates with lots of stuff including Axosoft, Gitlab.com, and others.

https://www.youtube.com/watch?v=IVDocdM9tN4

I get the idea that like some other integrations that I've seen cropping up, since it's a SaaS platform only, it's not applicable to any private gitlab instances, that is, it can only used if you're using gitlab.com, although it might work if your "private" gitlab is internet routable, which I believe most Gitlab EEs are not.

But this solution is worth comparison-studying. I personally think Omnibus Gitlab EE should have its own timesheet solution, a "simple" opinionated (less flexible, zero or very few configuration options) solution for private Gitlab EE installs.

mentioned in issue #1490 (closed)

changed title from User timesheet to Export user time tracking information

@regisF : Since time tracking is associated directly with issues / merge requests, and indirectly with users, let's focus on exporting issues first? (I.e., if we associate it with users, we need to check assignees, or who entered a comment to activate time tracking, etc. And we would have to make certain assumptions.) So let's do exporting time tracking info with issues first?

We can simply add time tracking information to this feature right? https://gitlab.com/gitlab-org/gitlab-ee/issues/1480.

@victorwu we can do that indeed. However, I'm not sure that the current proposal of the issue you indicate, contains time tracking data as a first iteration.

@regisF : Sorry, yeah, I wasn't proposing on squeezing that into #1480 (closed). That's already close to being done.

I'm going to simply re-use this issue here to adding time tracking info as a next iteration. But that's only on the project list view right? And then users can simply sort/filter by user in their spreadsheet app to get user-based info.

We can then have separate issues to see if we need to do it in a group, instance level, if at all. But just having it as an update there I think already will solve many problems for customers.

changed title from Export user time tracking information to Export issue time tracking information

changed milestone to %9.1

added deliver label

added Deliverable and removed deliver labels

@smcgivern : I think simply adding two additional columns to the csv export. I don't see any other UI / customer-facing feature that needs to be updated. Thanks!

changed milestone to %Backlog

added ~897283 ~1012342 and removed Deliverable labels

added ~874214 label

changed milestone to %9.2

added Deliverable label

removed ~897283 ~1012342 labels

added Stretch label

removed Deliverable label

Is this going to be implemented in 9.2? Would be very much appreciated!

removed Stretch label

added Deliverable label

@simon.allendoerfer : No, it didn't make it into 9.2. Apologize for not updating it earlier.

changed milestone to %9.3

removed milestone

changed milestone to %Backlog

@victorwu Okay, thank you. This issue is very important to me. What can I do to help it getting delivered in 9.3?

Thanks @simon.allendoerfer . Currently this is not scheduled for anyone to work on.

Since the requirements are fairly straightforward, I marked it as Accepting Merge Requests , so if you would like, you can definitely contribute code. If you are able to finish a merge request and someone on our team can review and merge it by June 7 (code freeze for 9.3), it should make it into the June 22nd (9.3) release. If you would like to work on it, please let me know, and I can assign it to you.

@DouweM : Can you please confirm that this is okay.

We are not a Ruby shop, so setting everything up and testing it, would not make much sense for us.

As far as a quick look can tell, you only have to add something like this (again, don't know ruby) to app/services/issues/export_csv_service.rb in line 45.

        'Time Spent' => -> (issue) { issue.total_time_spent },

Afterwards add a check to spec/services/issues/export_csv_service_spec.rb.

Maybe a Ruby dev can create a quick PR.

@simon.allendoerfer Thanks to our GitLab Development Kit, "setting everything up and testing it" is as simple as installing a few dependencies and running a few commands that perform the setup; it literally takes only a few minutes.

I'll be happy to assist and review and eventual merge request, but we can only have our people work on so many things at the time, and currently this is not on our list of priorities.

added Accepting Merge Requests label

added EE Starter label

changed the description

@g3dinua : The existing CSV export functionality is in EES (https://docs.gitlab.com/ee/user/project/issues/csv_export.html). So this feature will also be in EES. If you are fine with the requirements in the description, you can certainly work on it, and our dev team should be able to help review your merge request. So let me know if that works, or you would like to work another feature first.

@smcgivern : I updated the description to say that the output of the time tracking fields should be in seconds. I think if this is handled in Excel, it makes sense that there is some standard, and the person using Excel can use formulas to manipulate it. So it's better than outputting someone like 3d 4h, which could be harder to manipulate. Choosing seconds is arbitrary. Thoughts?

@victorwu starting with that today, will create MR with this soon.

@victorwu yep, makes sense to me.

removed Accepting Merge Requests label

Thanks @g3dinua . Please ping myself and @smcgivern on the merge request.

changed milestone to %10.0

assigned to @victorwu

@victorwu @smcgivern hi guys, unfortunately, we can't create MR, coz can't fork gitlab ee repo: http://d.pr/i/SUCZvH

Here is commit for this task: https://gitlab.com/LockiStrike/gitlab-ee-cloned/commit/e50be8d574fd0729260a9738665572cfd17cc3d3, could you please share your feedback about it and advise how to merge it?

@g3dinua that's weird, I can't see why you'd get that error. Does it happen every time? I was just able to fork that repo successfully.

If it never works, I can cherry-pick that commit and create an MR on your behalf. Why do we need the rjust on the numbers?

assigned to @g3dinua and unassigned @victorwu

assigned to @smcgivern

@smcgivern

that's weird, I can't see why you'd get that error. Does it happen every time? I was just able to fork that repo successfully

Tried several times from different accounts. If you can fork on behalf of my user I'll appreciate it.

do we need the rjust on the numbers?

to have result "with 5 decimal places in the CSV file", but we can remove rjust if that's overkill

@g3dinua:

Tried several times from different accounts. If you can fork on behalf of my user I'll appreciate it.

I can't do that, but I've given you push access to my fork: https://gitlab.com/smcgivern/gitlab-ee

to have result "with 5 decimal places in the CSV file", but we can remove rjust if that's overkill

Ah, 5 decimal places in this case means after the decimal separator, not before it.

@smcgivern

I can't do that, but I've given you push access to my fork

thanks, will push branch here

decimal places in this case means after the decimal separator, not before it.

how can we have a situation, when a user logged value that is less than second? in any case, will add value rounding here.

@g3dinua if you don't think it makes sense, we can ignore it for now Please ping me when you've created the MR!

mentioned in merge request !2627 (merged)

marked this issue as related to #1312

closed via merge request !2627 (merged)

mentioned in merge request !2884 (merged)