Super-productivity: [Feature request] Submit Jira Worklog before task completion

[endorama]

Currently it seems that Jira worklog is submitted to the related issue only when it's marked as complete from the interface. This makes really hard tracking time on issues not assigned to oneself, or to inspect worklog during the week.

Would be possible to submit the worklog at other times? For example when clicking on the "Finish and go home button".

Thanks!

(If the feature is accepted, I can try contributing to the project and implement it!)

[johannesjo]

Hey there! Thanks for the suggestion! Generally I like the idea, but I'm not sure how this should work if you have worked on multiple issues, e.g. if there automatically is opened a new Dialog for every issue worked on, etc..

Alternatively maybe there could be an extra button for that inside the task list tab and the week tab on the daily summary screen.

Btw.: It's currently also possible to trigger submitting the worklog once a sub task is done. Not sure if that helps with your use case.

[johannesjo]

I'm closing this due to inactivity.

[jac1013]

Hey @johannesjo can we reopen this? I can contribute on this if needed, maybe having an option in the vertical ellipsis button of tasks to "sync" the worklog with JIRA.

[endorama]

I just get bitten by the behaviour described in #176.

As a note to anyone implementing this, any action that sends the worklog to Jira should "remeber it" to avoid sending it twice.

@jac1013 just my 2c but an option there would be more than enough!

[jac1013]

@endorama you are right, I commented about the "remember" behavior in #176, I'll work on this whenever the duplication issue is solved.

[johannesjo]

@jac1013 that's great to hear. The issue should be resolved, but there isn't just a new release ready. I 'll make one later today.

[jac1013]

Thanks @johannesjo I'll tackle this in the weekend.

[jac1013]

As a note to anyone implementing this, any action that sends the worklog to Jira should "remeber it" to avoid sending it twice.

@johannesjo I noticed that before having this we need what @endorama pointed out here. I want to know first if this is something you think should be done before trying to come with a solution for it.

I saw that the problem is that worklogs are not saving the ID from JIRA, because of that, we don't know if a worklog is created in JIRA or not so the system assumes that all the worklogs in an issue are intended to be created as worklog in JIRA (not correct, there could be old worklogs that are already created in JIRA).

So my question here is, do we want to change this? second question is: will you change it or should I give it a try?

[jac1013]

Ok guys, so I read the code a bit more to understand what's happening, I think a _decent_ solution for this is to always create a new worklog whenever the play button is clicked (this, only locally), also, when a worklog is created in JIRA we need to _mark them_ as submitted (or something like that) so we don't create new worklogs in JIRA out of those (which will be duplicates).

The problems that the current approach of using a single worklog per issue are:

• If we log some time into an issue, complete it, save the worklog and reopen that issue to complete it again when saving the worklog this second time it will save the time we already submitted into JIRA (ending up with a duplicate).

• When working with an issue through multiple days the worklog will always say the same initial starting date, not reflecting the reality of how the issue was tackled by the developer from the time perspective.

• With this problem in place, having a button to update the worklog without completing the task doesn't make sense, that button will be creating duplicates which is wrong.

Updating the worklog is not an option because we will still end up with a worklog that has a starting date for the first log and it is modified multiple times (not reflecting reality). Plus, the JIRA client library that the project is using doesn't have a wrapper to update a worklog (complicating things even more).

[johannesjo]

@jac1013 thanks for digging into to this. Not really sure what a good solution could be for the problems your described. There will be definitely cases where it will be hard to impossible to make assumptions what the right thing to do is. People use the time tracking features in different ways. For some just the rough amount of time spent is important and they don't want to be annoyed with having to make choices all the time and been shown too much information they're not interested in. For others you need the exact periods and it would be good to have a way to do so.

Another thing complicating this even further are special cases for what should happen if a task get's - locally - deleted or restored after deletion. Should the already submitted worklogs be then deleted or restored too? What happens if this is not possible due to some restrictions being in place on jira, e.g. a task can't be updated because it is already marked as completed there. Also it seems like that the time tracking feature is not even shown any more in the newest versions of jira (even though the model is still in place) but don't know anything specific about this...

The approach so far has been, to only loosely connect the two models and let the user decide on what to track, and what not. I'm glad for any ideas on how to better support the user on this.

[endorama]

Assuming that we know start date and time and duration of a worklog, is it
possibile to use this to map "local to remote" worklogs?

So we should be able to "ignore" remote worklogs with matching data even
without an explicit id.

Does it make sense? It feels "loosely coupled" to me :)

>

[endorama]

Looking at Jira API docs (
https://developer.atlassian.com/cloud/jira/platform/rest/v3/#api-rest-api-3-issue-issueIdOrKey-watchers-delete)
what I described should be doable.

I'd also noticed that there is an "id" field in the Worklog model, so we
may be able to use it locally?

This clashes with what is stated before:

I saw that the problem is that worklogs are not saving the ID from JIRA,
because of that, we don't know if a worklog is created in JIRA or not

So I'm a bit confused :)

>

[jac1013]

@johannesjo I like your approach of considering users first, I don't know how users are using the application nowadays, I think my case is one that is not considered from the core functionality of it (Having a task and log time to it multiple times without completing it). I don't see an easy solution for this, it will require multiple changes on how the worklogs are being handled today in the system.

@endorama Yes, the ID is missing in Super Productivity App, JIRA provides those of course.
@endorama I found a workaround for using SuperProductivity with this purpose, what I do is:

• While I'm working through my day I'll find JIRA tasks through SuperProductivity and start logging time into them (this creates a new worklog with today timestamp).
• At the end of the day I submit all the worklogs from different tasks that I worked in the day.
• After that I delete all the task from SuperProductivity (Locally, of course, through the vertical ellipsis option button).
• Next day I repeat, this will create different worklogs each day and it won't create duplicated worklogs because when we "delete" the task locally it removes all the worklogs associated to that task (locally, not in JIRA).

Cons of this: You will not have SuperProductivity Metrics, for my use case, this is not important (I'd love to use metrics in SP but oh well, we can't have our cake and eat it too ;) ).

EDIT: Actually, I was wrong about the metrics, it seems like I wasn't understanding how SP is meant to be used, using the "Finish working" button will remove all completed task, to me, it seems, that this is exactly what I needed :).

[jac1013]

Ok guys, so I've been using SP this whole week, so I'm going to clarify some points about my previous post.

EDIT: Actually, I was wrong about the metrics, it seems like I wasn't understanding how SP is meant to be used, using the "Finish working" button will remove all completed task, to me, it seems, that this is exactly what I needed :).

This is not like I described in my edit, when we "Finish working" all tasks are gone (good), when we find the task again they will have the worklog of the previous day, meaning that the worklog will be entered in JIRA again whenever we finish that task and upload the worklog to JIRA (again).

While I'm working through my day I'll find JIRA tasks through SuperProductivity and start logging time into them (this creates a new worklog with today timestamp).
At the end of the day I submit all the worklogs from different tasks that I worked in the day.
After that I delete all tasks from SuperProductivity (Locally, of course, through the vertical ellipsis option button).
Next day I repeat, this will create different worklogs each day and it won't create duplicated worklogs because when we "delete" the task locally it removes all the worklogs associated to that task (locally, not in JIRA).
Cons of this: You will not have SuperProductivity Metrics, for my use case, this is not important (I'd love to use metrics in SP but oh well, we can't have our cake and eat it too ;) ).

So this is really the workaround for me so far, and yes, the metrics are gone.

[alexembley]

Is help still required on this issue? I would be willing to put some time into getting this completed

[johannesjo]

@alexembley yes, help is always appreciated. To be honest it's still a bit unclear what the best approach would be for this. Maybe using a custom panel for the daily summary is an option? This way we could also integrate other time tracking providers.

[bevrard]

Daily or weekly? :-) I like the idea to integrate other providers. It would be great to integrate an ical calendar. It would be the perfect summary of the week: tasks and meetings.

[johannesjo]

Daily or weekly?

Could be both I guess :)

[cufiler]

Hi all
What I find is that in file src/app/features/issue/providers/jira/jira-view-components/dialog-jira-add-worklog/dialog-jira-add-worklog.component.ts this line refers to task instead of tick
this.started = this._convertTimestamp(this.data.task.created);

I think it needs to use tick.timestamp at this point.

About @jac1013's workaround... I don't delete tasks but add subtasks when start to work in an issue. So the subtask created timestamp is today. When I finish this subtask, it is populated to Jira starting at the time of creation (=start or work). The super-productivity's sub-task is going to be a Jira's workload.
Actually, I have an issue with the start time as it is using Zulu time but this is another question.