https://www.redmine.org/https://www.redmine.org/favicon.ico?16793021292013-12-13T19:26:54ZRedmineRedmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=538072013-12-13T19:26:54ZDipan Mehta
<ul></ul><p>+1. This is very important. Many a times versions are full projects or sprints where start and end dates are useful.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=538492013-12-16T09:26:30Zdjiby thiaw
<ul></ul><p>Agree with you Dipan. So I hope that redmine team will do that in newer versions of the product</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=622142015-03-13T08:15:54ZGo MAEDA
<ul><li><strong>Has duplicate</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/19367">Feature #19367</a>: please add 'start date' for version</i> added</li></ul> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=631562015-04-16T04:36:57ZAmi Desai
<ul></ul><p>Still not available in version 3.0.</p>
<p>Please kindly include this feature soon.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=699132016-03-24T12:15:34ZAmr Noaman
<ul></ul><p>+1 The issue is that it is misleading. new users enter the start date of the version instead of the due date. At least, rename the label to be 'due date' instead of just 'date'</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=699172016-03-24T12:52:34ZGo MAEDA
<ul><li><strong>Related to</strong> <i><a class="issue tracker-3 status-5 priority-4 priority-default closed" href="/issues/22315">Patch #22315</a>: Change English translation for field_effective_date: "Date" to "Due date"</i> added</li></ul> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=699202016-03-24T12:59:40ZGo MAEDA
<ul></ul><p>Amr Noaman wrote:</p>
<blockquote>
<p>At least, rename the label to be 'due date' instead of just 'date'</p>
</blockquote>
<p>I have submitted a patch: <a class="issue tracker-3 status-5 priority-4 priority-default closed" title="Patch: Change English translation for field_effective_date: "Date" to "Due date" (Closed)" href="https://www.redmine.org/issues/22315">#22315</a></p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=704892016-04-22T06:19:01ZToshi MARUYAMA
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/70489/diff?detail_id=54741">diff</a>)</li></ul> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=704902016-04-22T06:19:27ZToshi MARUYAMA
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/70490/diff?detail_id=54742">diff</a>)</li></ul> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=790892017-06-08T08:42:12ZGo MAEDA
<ul></ul><p>+1<br />With this feature, we can see implementation period of the version in gantt. It is really useful.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=867972018-08-26T21:33:36ZMarius BĂLTEANU
<ul><li><strong>File</strong> <a href="/attachments/21324">start_date.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/21324/start_date.png">start_date.png</a> added</li></ul><p>Go MAEDA wrote:</p>
<blockquote>
<p>+1<br />With this feature, we can see implementation period of the version in gantt. It is really useful.</p>
</blockquote>
<p>Totally agree. For example, in our instance, because we do not use start date for issues, we've created from the beginning a custom field to store the Start Date of the version, but is not so useful because is not used by any other Redmine feature. Furthermore, is quite confusing to have the due date first and after that the start date (screenshot attached).</p>
<p>I would like to work on this, but I'm not sure how to implement it considering the current functionality. I have 3 scenarios in mind:</p>
1. A global setting to choose how the start date of the version should be calculated:
<ul>
<li>minimum start date from the issues (current implementation)</li>
<li>independent from issues</li>
</ul>
<p>2. Above setting but at version level<br />3. No setting and use the start date from the issues when the Start date field of the version is not filled (it can be quite confusing for users).</p>
<p>I think that I prefer the first option.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=868802018-09-01T03:18:56ZGo MAEDA
<ul></ul><p>Marius BALTEANU wrote:</p>
<blockquote>
<p>I would like to work on this, but I'm not sure how to implement it considering the current functionality. I have 3 scenarios in mind:</p>
1. A global setting to choose how the start date of the version should be calculated:
<ul>
<li>minimum start date from the issues (current implementation)</li>
<li>independent from issues</li>
</ul>
<p>2. Above setting but at version level<br />3. No setting and use the start date from the issues when the Start date field of the version is not filled (it can be quite confusing for users).</p>
</blockquote>
<p>I prefer the third option. Currently, Redmine uses the earliest start date of the issues as version's start date (<code>Version#start_date</code>). The behavior of the third option is compatible with the current behavior and I think it can avoid confusing existing users.</p>
<pre><code class="ruby syntaxhl"> <span class="k">def</span> <span class="nf">start_date</span>
<span class="vi">@start_date</span> <span class="o">||=</span> <span class="n">fixed_issues</span><span class="p">.</span><span class="nf">minimum</span><span class="p">(</span><span class="s1">'start_date'</span><span class="p">)</span>
<span class="k">end</span>
</code></pre> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=868882018-09-01T10:10:39ZMarius BĂLTEANU
<ul><li><strong>File</strong> <a href="/attachments/21347">0001-Add-start-date-to-versions_WIP.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/21347/0001-Add-start-date-to-versions_WIP.patch">0001-Add-start-date-to-versions_WIP.patch</a> added</li></ul><p>Thanks for your feedback, Go Maeda.</p>
My concern with this option is the following scenario:
<ul>
<li>add a version without start date</li>
<li>add at least one issue with start date to the version</li>
<li>now, the version has the start date of the issue (current behaviour which is correct)</li>
<li>open the edit version page</li>
<li>observe that the start date field is filled with the start date of the issue, even if in the database, the start date is nil</li>
<li>save the form </li>
<li>the value will be saved in the database and the version will no longer take into consideration the earliest start date of the issues</li>
</ul>
<p>Attached is a WIP patch to test the above scenario.</p>
<p>If you have any idea how to prevent this without adding a setting, please let me know. I'm very interested to have this feature.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=870732018-09-08T07:28:33ZMarius BĂLTEANU
<ul><li><strong>Assignee</strong> set to <i>Go MAEDA</i></li></ul><p>Go Maeda, please assign me after you are able to test the scenario.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=870742018-09-08T07:29:04ZMarius BĂLTEANU
<ul><li><strong>Category</strong> changed from <i>Project settings</i> to <i>Roadmap</i></li></ul> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=892462019-01-07T04:32:07ZMarius BĂLTEANU
<ul></ul><p>Go Maeda, you're still interested on this feature? If yes, please let me know what do you think about my above concerns. I would like to propose an implementation of this feature for <a class="version" href="https://www.redmine.org/versions/127">4.1.0</a> and right now I'm in favour of adding a setting.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=943582019-10-16T12:01:57ZSebastian Paluch
<ul></ul><p>+1</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=943592019-10-16T20:26:16ZMarius BĂLTEANU
<ul></ul><p>Sebastian Paluch wrote:</p>
<blockquote>
<p>+1</p>
</blockquote>
<p>Sebastian, which option do you prefer from note-11?</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=943652019-10-17T08:04:08ZSebastian Paluch
<ul></ul><p>Marius BALTEANU wrote:</p>
<blockquote>
<p>Sebastian, which option do you prefer from note-11?</p>
</blockquote>
<p>I don't like 1. as this is another system wide setting, we have many groups working on projects, using different processes and having diffeent preferences. The issue parent-child related system settings are one of fire makers...<br />I don't like 2. as this is too much work to set this for every version. We have hundreds of them.<br />Any setting like that should be made at project level. This works best when combined with project "templates".</p>
<p>The 3. is a functional solution. Simplest one and settings can always be added on top of that in future versions. For us it is important to have something finally implemented.</p>
<p>BTW. How would all that align with "due date" behavior? The due data is now independent from issues. Should it be also changed in the way for consistency?</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=943762019-10-18T04:40:15ZBernhard Rohloff
<ul></ul><p>+1 for the 2nd proposal</p>
<p>Sebastian Paluch wrote:</p>
<blockquote>
<p>I don't like 2. as this is too much work to set this for every version. We have hundreds of them.<br />Any setting like that should be made at project level. This works best when combined with project "templates".</p>
</blockquote>
<p>What's the point? You have to set your start and end dates for each version, anyway. I think the effort of checking a box to set explicit dates is rather negligible. Having the setting in the version form makes the functionality comprehensible to the user. I would also toggle between a text field and the actual date fields based on the state of the checkbox.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=943832019-10-18T07:27:11ZSebastian Paluch
<ul></ul><p>Bernhard Rohloff wrote:</p>
<blockquote>
<p>+1 for the 2nd proposal</p>
<p>Sebastian Paluch wrote:</p>
<blockquote>
<p>I don't like 2. as this is too much work to set this for every version. We have hundreds of them.<br />Any setting like that should be made at project level. This works best when combined with project "templates".</p>
</blockquote>
<p>What's the point? You have to set your start and end dates for each version, anyway. I think the effort of checking a box to set explicit dates is rather negligible. Having the setting in the version form makes the functionality comprehensible to the user. I would also toggle between a text field and the actual date fields based on the state of the checkbox.</p>
</blockquote>
<p>You have answered your question already. Setting first an option/checkbox and then date in every version is two times more operations... and you get no benefit out of it, same behavior gives you 3rd proposal.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=943862019-10-18T08:53:27ZBernhard Rohloff
<ul></ul><p>Sebastian Paluch wrote:</p>
<blockquote>
<p>... Setting first an option/checkbox and then date in every version is two times more operations... and you get no benefit out of it, same behavior gives you 3rd proposal.</p>
</blockquote>
<p>Are we talking about changing dates of existing versions or about creating new versions at a scale of hundreds a day? Because from my standpoint as a user, clicking a single checkbox for every new version I create is not really a thing. Choosing the setting for the whole project feels a bit inflexible to me. Perhaps we can think about a mix of both. Having a default setting for new versions chosen on the project level but leaving it up to the creator to change it in the version settings form.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=984372020-07-02T23:03:22ZSebastian Paluch
<ul></ul><p>Is there any progress on this? It would be such improvement having this done, ether option 2 or 3 :)</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=1013362021-03-15T12:38:15ZBrice Beaumesnil
<ul></ul><p>+1 for me too.</p>
<p>It will be very useful</p>
<p>The start date need to be independent from issues</p>
<p>Because we can have an old issue already open from days... month... years ;) worked... just 10%... and complete after many version.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=1037192021-08-13T21:05:26ZMischa The Evil
<ul><li><strong>File</strong> <a href="/attachments/27887">0001-Add-a-start-date-to-versions.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/27887/0001-Add-a-start-date-to-versions.patch">0001-Add-a-start-date-to-versions.patch</a> added</li><li><strong>Assignee</strong> changed from <i>Go MAEDA</i> to <i>Marius BĂLTEANU</i></li></ul><p>Here's a complete patch that implements this feature in the way that is outlined by Marius in note-11 as scenario 3. It provides a workaround for the undesired behavior described by Marius in note-13.<br />The patch includes up-to-date test coverage that is partly adopted from the original ChiliProject implementation and that is updated to fit current Redmine.</p>
<p>Any feedback is welcome...</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=1037352021-08-14T10:03:31ZMischa The Evil
<ul></ul><p>Sebastian Paluch wrote:</p>
<blockquote>
<p>BTW. How would all that align with "due date" behavior? The due data is now independent from issues. Should it be also changed in the way for consistency?</p>
</blockquote>
<p>I've extracted this to issue <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Add a fallback-mechanism to Version#due_date similar to Version#start_date (New)" href="https://www.redmine.org/issues/35760">#35760</a>.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=1037812021-08-16T17:23:40ZMischa The Evil
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-4 priority-default" href="/issues/35760">Feature #35760</a>: Add a fallback-mechanism to Version#due_date similar to Version#start_date</i> added</li></ul> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=1037842021-08-16T17:47:26ZMischa The Evil
<ul><li><strong>Assignee</strong> changed from <i>Marius BĂLTEANU</i> to <i>Mischa The Evil</i></li></ul><p>I'm working on some improvements of my latest patch posted in note-25.</p> Redmine - Feature #15180: Start date on versionshttps://www.redmine.org/issues/15180?journal_id=1038672021-08-22T08:21:50ZMischa The Evil
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-4 priority-default closed" href="/issues/35454">Defect #35454</a>: Project lines on Gantt (nearly) all start on the same single date</i> added</li></ul>