Feature #15180
open
Start date on versions
0%
Description
Hi,
Why not to add start date on version. I know that you can do it with custom field but i think that its better to have a column start date directly in the entity version. And also, the translation of effective_date will be end date and not only date.
Files
Related issues
Updated by Dipan Mehta almost 11 years ago
+1. This is very important. Many a times versions are full projects or sprints where start and end dates are useful.
Updated by djiby thiaw almost 11 years ago
Agree with you Dipan. So I hope that redmine team will do that in newer versions of the product
Updated by Go MAEDA over 9 years ago
- Has duplicate Feature #19367: please add 'start date' for version added
Updated by Ami Desai over 9 years ago
Still not available in version 3.0.
Please kindly include this feature soon.
Updated by Amr Noaman over 8 years ago
+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'
Updated by Go MAEDA over 8 years ago
- Related to Patch #22315: Change English translation for field_effective_date: "Date" to "Due date" added
Updated by Go MAEDA over 8 years ago
Amr Noaman wrote:
At least, rename the label to be 'due date' instead of just 'date'
I have submitted a patch: #22315
Updated by Toshi MARUYAMA 
Updated by Go MAEDA over 7 years ago
+1
With this feature, we can see implementation period of the version in gantt. It is really useful.
Updated by Marius BĂLTEANU about 6 years ago
- File start_date.png start_date.png added
Go MAEDA wrote:
+1
With this feature, we can see implementation period of the version in gantt. It is really useful.
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).
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:
1. A global setting to choose how the start date of the version should be calculated:- minimum start date from the issues (current implementation)
- independent from issues
2. Above setting but at version level
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).
I think that I prefer the first option.
Updated by Go MAEDA about 6 years ago
Marius BALTEANU wrote:
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:
1. A global setting to choose how the start date of the version should be calculated:
- minimum start date from the issues (current implementation)
- independent from issues
2. Above setting but at version level
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).
I prefer the third option. Currently, Redmine uses the earliest start date of the issues as version's start date (Version#start_date). The behavior of the third option is compatible with the current behavior and I think it can avoid confusing existing users.
def start_date
@start_date ||= fixed_issues.minimum('start_date')
end
Updated by Marius BĂLTEANU about 6 years ago
Thanks for your feedback, Go Maeda.
My concern with this option is the following scenario:- add a version without start date
- add at least one issue with start date to the version
- now, the version has the start date of the issue (current behaviour which is correct)
- open the edit version page
- 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
- save the form
- the value will be saved in the database and the version will no longer take into consideration the earliest start date of the issues
Attached is a WIP patch to test the above scenario.
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.
Updated by Marius BĂLTEANU about 6 years ago
- Assignee set to Go MAEDA
Go Maeda, please assign me after you are able to test the scenario.
Updated by Marius BĂLTEANU about 6 years ago
- Category changed from Project settings to Roadmap
Updated by Marius BĂLTEANU almost 6 years ago
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 4.1.0 and right now I'm in favour of adding a setting.
Updated by Marius BĂLTEANU about 5 years ago
Sebastian Paluch wrote:
+1
Sebastian, which option do you prefer from note-11?
Updated by Sebastian Paluch about 5 years ago
Marius BALTEANU wrote:
Sebastian, which option do you prefer from note-11?
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...
I don't like 2. as this is too much work to set this for every version. We have hundreds of them.
Any setting like that should be made at project level. This works best when combined with project "templates".
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.
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?
Updated by Bernhard Rohloff about 5 years ago
+1 for the 2nd proposal
Sebastian Paluch wrote:
I don't like 2. as this is too much work to set this for every version. We have hundreds of them.
Any setting like that should be made at project level. This works best when combined with project "templates".
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.
Updated by Sebastian Paluch about 5 years ago
Bernhard Rohloff wrote:
+1 for the 2nd proposal
Sebastian Paluch wrote:
I don't like 2. as this is too much work to set this for every version. We have hundreds of them.
Any setting like that should be made at project level. This works best when combined with project "templates".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.
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.
Updated by Bernhard Rohloff about 5 years ago
Sebastian Paluch wrote:
... 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.
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.
Updated by Sebastian Paluch over 4 years ago
Is there any progress on this? It would be such improvement having this done, ether option 2 or 3 :)
Updated by Brice Beaumesnil over 3 years ago
+1 for me too.
It will be very useful
The start date need to be independent from issues
Because we can have an old issue already open from days... month... years ;) worked... just 10%... and complete after many version.
Updated by Mischa The Evil over 3 years ago
- File 0001-Add-a-start-date-to-versions.patch 0001-Add-a-start-date-to-versions.patch added
- Assignee changed from Go MAEDA to Marius BĂLTEANU
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.
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.
Any feedback is welcome...
Updated by Mischa The Evil over 3 years ago
Sebastian Paluch wrote:
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?
I've extracted this to issue #35760.
Updated by Mischa The Evil over 3 years ago
- Related to Feature #35760: Add a fallback-mechanism to Version#due_date similar to Version#start_date added
Updated by Mischa The Evil over 3 years ago
- Assignee changed from Marius BĂLTEANU to Mischa The Evil
I'm working on some improvements of my latest patch posted in note-25.
Updated by Mischa The Evil over 3 years ago
- Related to Defect #35454: Project lines on Gantt (nearly) all start on the same single date added