Feature #15180

Start date on versions

Added by djiby thiaw almost 7 years ago. Updated about 1 month ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:Go MAEDA% Done:

0%

Category:Roadmap
Target version:-
Resolution:

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.

start_date.png (62.6 KB) Marius BALTEANU, 2018-08-26 23:12

0001-Add-start-date-to-versions_WIP.patch Magnifier (2.39 KB) Marius BALTEANU, 2018-09-01 12:09


Related issues

Related to Redmine - Patch #22315: Change English translation for field_effective_date: "Dat... Closed
Duplicated by Redmine - Feature #19367: please add 'start date' for version Closed

History

#1 Updated by Dipan Mehta over 6 years ago

+1. This is very important. Many a times versions are full projects or sprints where start and end dates are useful.

#2 Updated by djiby thiaw over 6 years ago

Agree with you Dipan. So I hope that redmine team will do that in newer versions of the product

#3 Updated by Go MAEDA over 5 years ago

  • Duplicated by Feature #19367: please add 'start date' for version added

#4 Updated by Ami Desai over 5 years ago

Still not available in version 3.0.

Please kindly include this feature soon.

#5 Updated by Amr Noaman over 4 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'

#6 Updated by Go MAEDA over 4 years ago

  • Related to Patch #22315: Change English translation for field_effective_date: "Date" to "Due date" added

#7 Updated by Go MAEDA over 4 years ago

Amr Noaman wrote:

At least, rename the label to be 'due date' instead of just 'date'

I have submitted a patch: #22315

#8 Updated by Toshi MARUYAMA over 4 years ago

  • Description updated (diff)

#9 Updated by Toshi MARUYAMA over 4 years ago

  • Description updated (diff)

#10 Updated by Go MAEDA about 3 years ago

+1
With this feature, we can see implementation period of the version in gantt. It is really useful.

#11 Updated by Marius BALTEANU almost 2 years ago

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.

#12 Updated by Go MAEDA almost 2 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

#13 Updated by Marius BALTEANU almost 2 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.

#14 Updated by Marius BALTEANU almost 2 years ago

  • Assignee set to Go MAEDA

Go Maeda, please assign me after you are able to test the scenario.

#15 Updated by Marius BALTEANU almost 2 years ago

  • Category changed from Project settings to Roadmap

#16 Updated by Marius BALTEANU over 1 year 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.

#17 Updated by Sebastian Paluch 10 months ago

+1

#18 Updated by Marius BALTEANU 10 months ago

Sebastian Paluch wrote:

+1

Sebastian, which option do you prefer from note-11?

#19 Updated by Sebastian Paluch 10 months 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?

#20 Updated by Bernhard Rohloff 10 months 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.

#21 Updated by Sebastian Paluch 10 months 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.

#22 Updated by Bernhard Rohloff 10 months 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.

#23 Updated by Sebastian Paluch about 1 month ago

Is there any progress on this? It would be such improvement having this done, ether option 2 or 3 :)

Also available in: Atom PDF