Redmine

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".

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 Schlichting: 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

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.

Markus Schlichting: 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).