Defect #35454

Project lines on Gantt (nearly) all start on the same single date

Added by Markus Boremski 3 months ago. Updated about 1 month ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Gantt
Target version:-
Resolution:Invalid Affected version:4.1.2

Description

Could anyone tell me what exactly causes the start-date of a project-bar in gantt?
We have about 800 projects and many of them seem to start on 01-oct-2019 (2019-10-01):

This mostly happens for sub-projects, but not in general.

If I take a closer look on such a project and display everything, one can see that this project did not start on 01-oct-2019:

2021-06-24 12_57_33-Gantt-Diagramm.png (58.7 KB) Markus Boremski, 2021-06-24 13:02

2021-06-24 13_05_01-Gantt-Diagramm.png (144 KB) Markus Boremski, 2021-06-24 14:22


Related issues

Related to Redmine - Feature #15180: Start date on versions New
Related to Redmine - Feature #35761: Display Project#start_date and Project#due_date on projec... New
Related to Redmine - Feature #35762: Add an optional, explicit Project#start_date and Project#... New

History

#1 Updated by Markus Boremski 3 months ago

Maybe one can fix the wrong Images in my description?
Someone can give me some informations on what defines the start-date?

Thanks in advance.

#2 Updated by Bernhard Rohloff 3 months ago

  • Description updated (diff)

Markus Boremski wrote:

Maybe one can fix the wrong Images in my description?

done ...

Someone can give me some informations on what defines the start-date?

To my knowledge and experience the start date of a project ist the first planned start-date of an issue in that project.
Maybe you can make visible what's causing the start dates if you set the filter of the issue state to "any".

#3 Updated by Markus Boremski 3 months ago

Maybe one can fix the wrong Images in my description?

done ...

Thanks.. :)

Maybe you can make visible what's causing the start dates if you set the filter of the issue state to "any".

Thats what we see in my sceenshots. There ist no filter set.
To be sure I tried so set FIlter to "all".
No change: An empty project from 2019-Oct-01 to our first task.

#4 Updated by Markus Boremski 2 months ago

Hey,
does anyone see this too?
Can someone help me to figure out whats going wrong?

#5 Updated by Mischa The Evil about 1 month ago

  • Status changed from New to Needs feedback
  • Assignee set to Markus Boremski

Bernhard Rohloff wrote:

Markus Boremski wrote:

Someone can give me some informations on what defines the start-date?

To my knowledge and experience the start date of a project ist the first planned start-date of an issue in that project.

That's actually just one of the three factors of a project that contribute to the determination of the project's start date (see source:/trunk/app/models/project.rb@21173#L696). To list them all:
  • issues.minimum('start_date')
  • shared_versions.minimum('effective_date')
  • Issue.fixed_version(shared_versions).minimum('start_date')

This logic also holds true for the project's due date (see source:/trunk/app/models/project.rb@21173#L706).

@Markus: You most-likely have either:
  • A shared version with an implicit start date (given by an issue with a start date and which is targeted against that shared version) active within the project tree that contains this project start date. Note that this particular shared version can also be outside the project tree that contains this project start date as versions can also be shared with all projects.
  • A shared version with an explicit due date active within the project tree that contains this project start date. Note that this particular shared version can also be outside the project tree that contains this project start date as versions can also be shared with all projects.

I agree that this could be hard to trace-back to the version that is the culprit. If you have access to and are familiar with the Rails console you can run a query to find the particular version, like:

Version.where(start_date: "2019-10-01").pluck(:id)
or
Version.where(effective_date: "2019-10-01").pluck(:id)

This will give you a numeric_id of a version, which you can then use to find the project that the version belongs to with a query like:
Version.find('numeric_id').project.to_s

#6 Updated by Markus Boremski about 1 month ago

Hey,
thanks alot for your detailed feedback.
I was able to find the reason for this behavior with your hints.

Your suggested commands lead to:

>>> Version.where(start_date: "2019-10-01").pluck(:id)
Traceback (most recent call last):
ActiveRecord::StatementInvalid (Mysql2::Error: Unknown column 'versions.start_date' in 'where clause': SELECT `versions`.`id` FROM `versions` WHERE `versions`.`start_date` = '2019-10-01')

>>> Version.where(effective_date: "2019-10-01").pluck(:id)
=> []

But this brought me to the idea to search start-dates of isses:

>>> Issue.where(start_date: "2019-10-01").pluck(:id)
=> [230, 1309, 1505, 1574, 1575, 1623, 1636, 1649, 1672, 1674, 1676, 1677]

The fist one was a direct hit. #230 is bound to our backlog-version and this version is shared over all projects.
Then I deleted the start-date of this issue and the projects now start from a later date.
Since we still had many projects starting on the same date (2019-11-11) I walked this way over several iterations.
Now our "problem" is solved. (thanks alot!)

But I would like to leave one question here:
  • Can we say this is "expected behavior"?
    And if so: Should we think about excluding system-wide-shared-projects from having impact on the start-date of all projects?

Thank you.

#7 Updated by Mischa The Evil about 1 month ago

  • Assignee deleted (Markus Boremski)

Markus Boremski wrote:

[...]
thanks alot for your detailed feedback.
I was able to find the reason for this behavior with your hints.

You're welcome. I'm glad you were able to find the cause of your issue despite my botched queries.

Your suggested commands lead to:

The second result is ok. It shows that no version with that effective_date exists in your Redmine.
The first one is my mistake. It is caused by the fact that I came to and tested this issue while working on #15180, which adds the respective column to Versions. I'd forgotten about this while replying here. My apologies for that.

But this brought me to the idea to search start-dates of isses:
[...]

Good thinking... :grin:

But I would like to leave one question here:
  • Can we say this is "expected behavior"?
    And if so: Should we think about excluding system-wide-shared-projects from having impact on the start-date of all projects?

FWIW: I think we can say that this is the expected behavior given how project start- and due-dates are implemented for the Gantt view (this is currently still the only place where these dates are displayed/used) combined with the fact that system-wide-shared-versions can only be configured by users with admin permissions (and lesser-wide shared versions with accordingly appropriate permissions; see r3123 for #465).
Whether or not this is the desired behavior is IMHO more ambiguous. Though, given all the context I'd say yes to that question too. Basically, you share a version with a start date (derived from it's issues), which is used to derive the start date of projects, with all the projects in the Redmine system. Logic and reason tells me that we shouldn't handle such a situation differently. Even though I agree that the cause of issues like yours can be tricky to resolve within the current implementation.
FTR: the implementation of issues #15180, #35761 and #35762 can decrease the difficulty of "debugging" an issue like this to some extend.

#8 Updated by Markus Boremski about 1 month ago

Thanks for you feedback.

Since your description I now agree, that wen can say this behavior is expected.
So we can close this issue from my point.

I would be feeling honored to have this issue referenced with your newly created issues regarding this topic.

#9 Updated by Mischa The Evil about 1 month ago

#10 Updated by Mischa The Evil about 1 month ago

  • Related to Feature #35761: Display Project#start_date and Project#due_date on project show view added

#11 Updated by Mischa The Evil about 1 month ago

  • Related to Feature #35762: Add an optional, explicit Project#start_date and Project#due_date to projects added

#12 Updated by Mischa The Evil about 1 month ago

  • Subject changed from Gantt - Projectbars / (nearly) all Start on 2019-Oct-01 to Project lines on Gantt (nearly) all start on the same single date
  • Description updated (diff)
  • Status changed from Needs feedback to Closed
  • Resolution set to Invalid

@Markus: thanks for the feedback.

I've added the issue relations, clarified the subject to make this issue easier to find and modified the description accordingly.
I'll subsequently close this issue with the resolution set to 'invalid' given that the reported behavior is expected from the current implementation(s).

Also available in: Atom PDF