Defect #14086
closed
Better handling of issue start date validation
Added by Edgar H over 11 years ago.
Updated over 11 years ago.
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:
- Create an issue with start date and due date. (Let' say May 27 and May 31). I will refer this issue as IssueA.
- Create another issue. I will refer this issue as IssueB.
- 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).
- Modify IssueB and add a relation to "follow" IssueA. This will "push" IssueB and its subtask forward on time.
- Create a fourth issue with start date and due date as a subtask of IssueB. (Let's use May 29 and June 4).
- Redime will create the issue successfully.
- Try to modify this last created issue and change something with the exception of the start/due dates (may be description, title, anything).
- This time, Redmine will raise an "Start date is invalid" error and won't let modify the issue.
Expected behaviour:
- Trying to create the last issue on the steps above should raise the invalid start date error.
- 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.
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.
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"?
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 :)
- 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.
Also available in: Atom
PDF
Updated by 
Updated by