Project

General

Profile

Actions

Defect #14086

closed

Better handling of issue start date validation

Added by Edgar H almost 11 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Normal
Category:
Issues
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed
Affected version:

Description

I am opening a new issue as requested on #6378. On comment 16 of that issue gives the idea of what is the bug.

Steps to reproduce the problem:
  1. Create an issue with start date and due date. (Let' say May 27 and May 31). I will refer this issue as IssueA.
  2. Create another issue. I will refer this issue as IssueB.
  3. Create a third issue with start date and due date as a subtask of IssueB. (Let's use the same dates: May 27 and May 31).
  4. Modify IssueB and add a relation to "follow" IssueA. This will "push" IssueB and its subtask forward on time.
  5. Create a fourth issue with start date and due date as a subtask of IssueB. (Let's use May 29 and June 4).
    1. Redime will create the issue successfully.
  6. Try to modify this last created issue and change something with the exception of the start/due dates (may be description, title, anything).
    1. This time, Redmine will raise an "Start date is invalid" error and won't let modify the issue.
Expected behaviour:
  1. Trying to create the last issue on the steps above should raise the invalid start date error.
  2. On the displayed error, more information is needed. People may become crazy trying to figure out why that date is invalid. May be something line "Start/End date overlaps with a preceding or following issue"?

Note: It also affects the demo that was at http://demo.redmine.org the same date I posted this issue. In fact, I did the above steps on the online demo before posting this issue to confirm its current existence.


Related issues

Related to Redmine - Defect #6378: Subtask - Start is invalidReopened2010-09-13

Actions
Actions #1

Updated by Edgar H almost 11 years ago

I would like to suggest this to be marked with high priority because this causes loss of data silently. This is related to automatic updates through repository commits:

  • If I add a reference to the issue including "refs #ISSUEID" in the comment, that commit is not added to the "Associated revisions" of the issue.
  • If I log time including "refs #ISSUEID @XhYm" in the comment, the time is not logged.
  • If I mark the issue as resolved using "fixes #ISSUEID" in the comment, the issue is not marked as resolved.
Actions #2

Updated by Jean-Philippe Lang almost 11 years ago

Edgar H wrote:

Expected behaviour:
1. Trying to create the last issue on the steps above should raise the invalid start date error.

These checks were improved lately and current trunk is now working as expected, you get an "invalid start date" error when trying to create the last issue.

2. On the displayed error, more information is needed. People may become crazy trying to figure out why that date is invalid. May be something line "Start/End date overlaps with a preceding or following issue"?

Very true, this error message should be improved and include the minimum start date. Maybe someting like "Start date : cannot be earlier than 05/31/2013 because of preceding issues"?

Actions #3

Updated by Edgar H almost 11 years ago

Jean-Philippe Lang wrote:

These checks were improved lately and current trunk is now working as expected, you get an "invalid start date" error when trying to create the last issue.

Then, sorry about this. Hope these improved checks be included soon in a stable release.

Very true, this error message should be improved and include the minimum start date. Maybe someting like "Start date : cannot be earlier than 05/31/2013 because of preceding issues"?

Yes! That would be a great improvement! And I can see that you are already working on it :)

Actions #4

Updated by Jean-Philippe Lang almost 11 years ago

  • Subject changed from Start date is invalid when updating subtask to Better handling of issue start date validation
  • Status changed from New to Closed
  • Assignee set to Jean-Philippe Lang
  • Target version set to 2.4.0
  • Resolution set to Fixed

Edgar H wrote:

I would like to suggest this to be marked with high priority because this causes loss of data silently. This is related to automatic updates through repository commits

Yes, if a start date becomes invalid for any reasons, automatic updates (eg. commits, replies by emails) are all stuck. r11931 now prevents that by skipping validation if the start date is not changed during the update.

I'm closing it as all the problems reported here can be considered as fixed, thanks for pointing this out.

Actions

Also available in: Atom PDF