Feature #3322

Spent time allows Future date

Added by Nanda P over 9 years ago. Updated 4 months ago.

Status:NewStart date:2009-05-08
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Time tracking
Target version:Candidate for next major release
Resolution:

Description

When entering Spent time the date field allows future date.

Can we have a validation & a warning message?

0001-setting-to-not-allow-spent-times-on-future-dates.patch Magnifier (3.79 KB) Marius BALTEANU, 2018-04-08 14:14


Related issues

Related to Redmine - Feature #13596: Allow time logging only for open issues New
Related to Redmine - Feature #13244: Restrict log time for old days Reopened
Duplicated by Redmine - Defect #14840: Time logging shouldn't be possible for the future periods Closed

History

#1 Updated by Jean-Philippe Lang over 9 years ago

If I had this validation, I'm pretty sure that some users will complain about it.
Any other opinions?

#2 Updated by Olafur Gislason over 9 years ago

One possibility is a checkbox in project settings page that would turn on/off that validation.

This could in my opinion also apply to logging time on a closed issue. ( The checkbox ).

#3 Updated by Eric Davis over 9 years ago

I don't like the idea of adding another option to the project settings page. What if when a time was logged that is in the future, we display a message along the lines of "Time added successfully. This time was logged to a future date". That would at least make it visible to the user that they might have made a typo.

#4 Updated by Nanda P over 9 years ago

I agree with the warning message.

#5 Updated by Mischa The Evil over 7 years ago

  • Tracker changed from Defect to Feature
  • Subject changed from Spent time allows Future date" to Spent time allows Future date

#6 Updated by Go MAEDA almost 2 years ago

#7 Updated by Go MAEDA almost 2 years ago

#8 Updated by Go MAEDA almost 2 years ago

#9 Updated by Go MAEDA almost 2 years ago

  • Duplicated by Defect #14840: Time logging shouldn't be possible for the future periods added

#10 Updated by Toshi MARUYAMA almost 2 years ago

  • Related to Feature #13596: Allow time logging only for open issues added

#11 Updated by Toshi MARUYAMA almost 2 years ago

#13244#note-16 has patch.

#12 Updated by Marius BALTEANU almost 2 years ago

Jean-Philippe Lang wrote:

If I had this validation, I'm pretty sure that some users will complain about it.
Any other opinions?

I do not see an use case for adding spent times on future dates. In my opinion, a spent time added for tomorrow (for example) is just an estimation.

#13 Updated by Kirill Marchuk about 1 year ago

first of all, how is it that this FR duplicates #13244 ?

These are totally different things!

This issue goes about restricting time logging in FUTURE, to avoid cheating or mistakes.

Issue #13244 has it about restricting time logged on days, that are X and more days in the past, to ensure employees discipline and to avoid "forgetting to log time" issues

what can I as a Redmine user do, to have these 2 issues decoupled and let #13244 pass thru the pipeline and get merged into upstream Redmine ?

#14 Updated by Toshi MARUYAMA about 1 year ago

  • Duplicated by deleted (Feature #13244: Restrict log time for old days)

#15 Updated by Toshi MARUYAMA about 1 year ago

#16 Updated by Marius BALTEANU 5 months ago

  • File 0001-setting-to-not-allow-spent-times-on-future-dates.patch added

I made a patch that adds a new setting to the Time Tracking tab. Admins can now allows / or do not allows time logs on future dates. The default setting is to allow in order to not change the current behaviour.

#17 Updated by Go MAEDA 5 months ago

Marius BALTEANU wrote:

I made a patch that adds a new setting to the Time Tracking tab. Admins can now allows / or do not allows time logs on future dates. The default setting is to allow in order to not change the current behaviour.

Fine improvement! But I think it will be even better if the error is more specific, for example, "Future date is not allowed" instead of "Date invalid".

#18 Updated by Marius BALTEANU 5 months ago

  • File 0001-setting-to-not-allow-spent-times-on-future-dates.patch added

Go MAEDA wrote:

Fine improvement! But I think it will be even better if the error is more specific, for example, "Future date is not allowed" instead of "Date invalid".

Totally agree, I had this in mind after I retested my patch in this morning. Here is the updated one.

#19 Updated by Marius BALTEANU 5 months ago

  • File deleted (0001-setting-to-not-allow-spent-times-on-future-dates.patch)

#20 Updated by Go MAEDA 5 months ago

  • Target version set to Candidate for next major release

#21 Updated by Mischa The Evil 5 months ago

@Marius and @Go: please hold the presses on this issue/patch. I'll elaborate below.

Over the last year (!), I've been working – silenty, and in tiny iterations – on an extensive (last count: 124 local development commits, 1200+ diff-LOC) patch series for a third-party, covering four whole new timelog restrictions (among one covers this particular issue) and extensions over the two restrictions already implemented for #24005, in one coherent, consistent and tested implementation, where each restriction comes with its own project, user, group, role and administrator exclusion/inclusion settings.
This work-in-progress is currently (and finally) in its final stages and thus nearing completion. This would also come with proper, detailed documentation.

I think it's only a matter of weeks utmost before all the remaining 'work' (it's already feature complete) will be completed. Therefore, I'd like to ask you all sincerely to wait with any potential core integration of any patch for this issue (or issue's #13244 and #13596, for that matter) until I've been able to open-source (i.e. share) the finished patch series in a proper manner, here on redmine.org publicly.

Thanks in advance...

P.S.: @Marius, this is in no way meant as a review of your patch(es)... ;)
P.P.S.: off-topic note to self: review and/or change future strategy regarding issue-assignment to prevent other users, repeatedly, working simultaneously on the same issues as I am, thus wasting my or their time in the end.

#22 Updated by Marius BALTEANU 5 months ago

Mischa The Evil wrote:

@Marius and @Go: please hold the presses on this issue/patch. I'll elaborate below.

Over the last year (!), I've been working – silenty, and in tiny iterations – on an extensive (last count: 124 local development commits, 1200+ diff-LOC) patch series for a third-party ...

This is why Waterfall is so bad :)

This work-in-progress is currently (and finally) in its final stages and thus nearing completion. This would also come with proper, detailed documentation.

I think it's only a matter of weeks utmost before all the remaining 'work' (it's already feature complete) will be completed. Therefore, I'd like to ask you all sincerely to wait with any potential core integration of any patch for this issue (or issue's #13244 and #13596, for that matter) until I've been able to open-source (i.e. share) the finished patch series in a proper manner, here on redmine.org publicly.

Thanks in advance...

P.S.: @Marius, this is in no way meant as a review of your patch(es)... ;)
P.P.S.: off-topic note to self: review and/or change future strategy regarding issue-assignment to prevent other users, repeatedly, working simultaneously on the same issues as I am, thus wasting my or their time in the end.

I've invested only one hour in developing this patch, so is not a big waste from my point of view. I'm happy that you post your plan here because i's also in my plan for this week to develop the restriction for #13244. My main problem here is that we really need these 2 features internally next week, so I can't wait too long. Can we continue this discussion in private? Maybe we can find together a better solution.

#23 Updated by Go MAEDA 5 months ago

I am very looking forward Mischa's work. Aside from it, I found that Marius's patch may not work depending on time zones.

Suppose that time-zone of the user is set to Tokyo (+0900) and the server is set to UTC. If the user tries to log time for today at 08:00 on April 1 in Tokyo (23:00 UTC on March 31), the user cannot log time and see "Cannot log time on a future date" error. This is because TimeEntry#spent_on is April 1 and the server's date is March 31. In this situation, TimeEntry#spent_on.future? returns true and the user sees the error message.

#24 Updated by Marius BALTEANU 5 months ago

  • File deleted (0001-setting-to-not-allow-spent-times-on-future-dates.patch)

#25 Updated by Marius BALTEANU 5 months ago

  • File 0001-setting-to-not-allow-spent-times-on-future-dates.patch added

Go MAEDA wrote:

I am very looking forward Mischa's work. Aside from it, I found that Marius's patch may not work depending on time zones.

Suppose that time-zone of the user is set to Tokyo (+0900) and the server is set to UTC. If the user tries to log time for today at 08:00 on April 1 in Tokyo (23:00 UTC on March 31), the user cannot log time and see "Cannot log time on a future date" error. This is because TimeEntry#spent_on is April 1 and the server's date is March 31. In this situation, TimeEntry#spent_on.future? returns true and the user sees the error message.

I've fixed the issue, thanks for feedback.

I'm attaching the patch here for those who need this feature until Mischa's work is public and ready. Also, I don't see any problem to have this committed for the next version and override by Mischa patches in the future.

#26 Updated by Marius BALTEANU 4 months ago

  • File deleted (0001-setting-to-not-allow-spent-times-on-future-dates.patch)

#27 Updated by Marius BALTEANU 4 months ago

Another update with two fixes:
- take into account the time zone of the time entry author and not of the current user.
- apply the validation only when the spent on date was changed (to follow the implementation from #24005).

Also available in: Atom PDF