View Issue Details

IDProjectCategoryView StatusLast Update
0023729mantisbttime trackingpublic2017-12-15 08:13
Reporterethraza Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Product Version2.9.0 
Summary0023729: Stopwatch loses its content on page reload
Description

When you have the Stopwatch running, forgets about it and click somewhere else on the page, the time counting gets lost.

Steps To Reproduce

Start the Stopwatch and click any link or button on Mantis, or just reload the page.

Additional Information

What I propose:
The last change I have made to the Stopwatch was to set a timestamp on start and just show in the counter the diff between start time and now.
So I propose to get this start timestamp recorded to browsers Local Storage instead of plain memory variable, so the page can be left and the counter will still know its content when the user comes back.

In fact I believe it would be a good idea to get 4 information recorded.
1- Timestamp
2- Stopwatch status (running/paused)
3- Issue ID
4- User ID

It would allow the Stopwatch to show the running time when paused or the continuos running time from start till now, for the user logged in and, for that specific issue, allowing MantisBT users to have running times for multiple issues at the same time.

TagsNo tags attached.

Activities

cproensa

cproensa

2017-12-14 09:46

developer   ~0058389

Something like described is implemented in the development of time tracking plugin. See 0021572

Do you think you could help in testing and improving that plugin?

ethraza

ethraza

2017-12-14 10:07

reporter   ~0058390

What I didn't like on this plugin is that it's not using the built in time tracking code. It's not even using the same approach. In the plugin, the time is disassociated from activities, what does not make sence to me, because activities takes time to be accomplished and if you just record lose times, you will lost track of what took that times to be acomplished.

I was even thinking in create an issue asking if it's possible to extract the bultin Mantis time tracking as a plugin. That would be optimal imho.
If the buildin time tracking get just striped out in favor of this actual plugin as is, I would be obligated to fork Mantis and keep using the version with builtin time tracking, because it just works.

cproensa

cproensa

2017-12-14 10:19

developer   ~0058391

@ethraza
Did you check the repository refrenced at ~c57507 ?
https://github.com/mantisbt-plugins/timetracking/tree/next

I was even thinking in create an issue asking if it's possible to extract the bultin Mantis time tracking as a plugin. That would be optimal imho.

The re-implementation of the plugin is dedicated to achieve exactly that.

ethraza

ethraza

2017-12-14 10:50

reporter   ~0058392

Yes, I have installed this plugin to test and come to the conclusion it is too lacking to be usable.
My CTO told me to uninstall the plugin and use the bultin time tracking for now and, if I cannot get little stuff fixed, to go for another solution, like Kimai or something else.
So I decided to try to improve the bultin time tracking. But if this contributions are not welcome in the core or they are going to get lost in a close future transition to the plugin, I would like to know, so I can keep than to the necessary minimum, because if I'm not helping, well, I'm not helping. Some contributions I do because we need here, but some I choose to do because I think they are good improvements to Mantis, and since we don't contribute to the project with money, we may contribute with code.

But just to let it clear, since it may be lost in my ability to comunicate it in english, I don't hate the plugin or something like that, it just does not fit in the problem we have here today. But the builtin fits, with this minor fixes. In reallity, what I did that will already be merged in 2.10.0 is enough for our use. What I'm proposing now are just enchacements to get it better and is the way I found to help MantisBT project.

cproensa

cproensa

2017-12-14 19:16

developer   ~0058396

But just to let it clear, since it may be lost in my ability to comunicate it in english

neither i am english native, no problem here.

my insistence is: did you try the master branch from the plugin? which is an old plugin, almost unmantained, and clearly feature lacking,
or the next branch? (the one i directly linked), which is a reimplementation of the built-in timetracking, as an external plugin

But if this contributions are not welcome in the core or they are going to get lost in a close future transition to the plugin

No, contributions are welcomed, and the fact that yours have been accepted is a good sign that your work has been good and appreciated. Note that core developers sometimes have busy periods out of the mantis project, and sometimes pull request can be stalled for some time waiting for feedback, approval, etc.

Removing built in timetracking in favour of a plugin implementation is not a decission that has been officially made yet. I made the proposal and support it, reasoning that

  • this functionality is old and hasn't been mantained or improved for a very long time.
  • Has its logic interleaved with the core apis and data structure, and not in a clean way.
  • This functionality is perfectly suitable to be implemented as a plugin
  • By decoupling it from mantis core api and data structures, it allows a less restricted, fastest path for improvements without affecting mantis core.

As a start, i implemented that plugin branch, even if it's still a work in progress, it has:

  • upgradeable from the old TT plugin
  • migration tool to import the built-in TT data
  • allow entering time entries, as apart of a bugnote, or independent entries.
  • edit existing time entries
  • support categories for time entries
  • reporting groupable by project, user, category, issue...
  • persistent (server side) stopwatch

as a WIP, it still lacks:

  • more work on the reports
  • export the reports
  • billing

Now, regarding some of the topics:
Billing:
Note the current built-in TT billing, is really simplistic: put a number in the report, and multiply time to paint the amount in the report.
A straight improvement is to have some master data for: price per hour, configurable by project, time category, even by specific user...

Stopwatch:
The mentioned new approach is to have a global stopwatch per user. The time is kept at server side for better precission and persistence. When you stop the stopwatch, you can use that time as a time entry for some issue.
However, this doesn't support having several stopwatches running simultaneously for different issues. I don't see the real case. Are you working on several task at the same time? shouldn't your measured spent time be billable to one issue at a time?
However, you could add another point of view, and anything that is reasonable, and flexible for the common use cases, can be implemented

Most importantly:
Probably, a contributor like you is the perfect scenario to better improve the new plugin, becasue you are an active user with real world needs, ideas, usage, and testing.
I don't use time tracking at the moment, so my motivation is to provide a factible path to migrate the functionality out of mantis core

ethraza

ethraza

2017-12-15 08:13

reporter   ~0058398

Oh dude, now I see it! I never understand it because I indeed tested the Master branch, and didn't noticed the Next branch link because the Readme is similarly empty. I can just imagine how many people tried the Master branch and quit looking for this plugin because it's lacking and say nothing about further development! Now that I know that, I'll try it.
That simple esplanation you just gave to me could go into the TT plugin Readme to cast some light over it.

Abou billing:
Yeah, I know that a lot of people around there would need to have different rates for different costumers or services. Here in my company it just happens to be more simplistic and we have just one rate for everything that deserves to be tracked.

About the stopwatch:
My only usage for this would be if I'm working on T1 and then something happens that force me to start T2 and forget the T1, then when I finish T2 I could go back to T1 and continue where it was left. In this scenario, just one stopwatch would be running at a time, and when I start a new one, the last one needs to automatically pause.

About have the TT plugin or built-in:
I guess Mantis core members should just have a vote or something and decide once and for all, so everybody can focus in the right thing. I myself have no preference for TT keep built-in or going plugin, It just need to be embraced and well documented for the sake of users.