Feature #716
closedRemove default start date
Added by Joris Verschoor over 16 years ago. Updated over 10 years ago.
0%
Description
Start date should not be filled in by default. Creating an issue does not automatically mean that someone is working on it.
A creteiondate should be used instead.
Also, the startdate COULD be enabled for certain statusses. For example:
ASSIGNED -> fill startdate
FIXED/CLOSED -> fill enddate
If start is an indication of when someone should start, you should fill in due-date, and substract estimated-hours/8 = days.
Files
Option-StartDate.png (16 KB) Option-StartDate.png | Olivier Houdas, 2014-03-07 15:16 |
Related issues
Updated by Wynn Netherland about 16 years ago
I'd like to see this removed or opt-in only. In our process, we almost never begin work on a ticket the day that it's logged.
Joris Verschoor wrote:
Start date should not be filled in by default. Creating an issue does not automatically mean that someone is working on it.
A creteiondate should be used instead.Also, the startdate COULD be enabled for certain statusses. For example:
ASSIGNED -> fill startdate
FIXED/CLOSED -> fill enddateIf start is an indication of when someone should start, you should fill in due-date, and substract estimated-hours/8 = days.
Updated by Eric Davis almost 16 years ago
I agree with removing the start date, I don't use it and when I do there is too many issues with the default start date to make it useful.
I disagree with automatically adding the start date for different statuses. Status names can be changed by an Administrator and we might not always have a "Assigned" status.
I also disagree with "If start is an indication of when someone should start, you should fill in due-date, and substract estimated-hours/8 = days." Not everyone works 8 hours, it will not account for weekends, days off, holidays, and that's assuming someone works on an issue 100% of the time with no slack time.
Updated by Mischa The Evil almost 16 years ago
Joris Verschoor wrote:
A creteiondate should be used instead
Wynn Netherland wrote:
In our process, we almost never begin work on a ticket the day that it's logged
Eric Davis wrote:
I don't use it and when I do there is too many issues with the default start date to make it useful
I think about this as if it is a multi-interpretable name for something that is in imho a quite important fact: the start-date of the issue (ticket). From that moment on all updates of that ticket should be done as comments. Besides some exceptions (typos, inline-corrections etc.) the original issue shouldn't be modified afterwards.
When an update is forced it's always traceable through the issues journal. At the same time it is always clearly visible to find the date of the last update of the issue on the issue itself.
This is what I mean by multi-interpretable; I see the start-date as the moment the issue got filed. You can either interpret it as the moment someone starts work for the issue.
Though imho both interpretations can be easily followed: It probably won't be much more than a simple change in the respective language-files
Updated by Mischa The Evil over 15 years ago
Just a new journal to push email updated: Related Patch #2269 can maybe solve the issue for both "camps"...
Updated by Douglas Cox about 14 years ago
I just ran into the same need. Our current task tracking system maintains the "Created" date of the task, but the "Start" date is the date someone should start working on it.
Was there an option that I missed to turn off defaulting the start date to "Today" and/or a way to have changing the status to "In Progress" to set it automatically to Today?
As a manager on larger projects, I would like to assign start dates for other users for scheduling purposes. For other small projects it is nice to see a valid start date when someone begins working on the task (In Progress) and have the Gantt Chart then show it.
I'm also interested in peoples thoughts on how useful a hard-coded End Date is vs. it being calculated based on the start date (possibly calculated from a dependent task) and a task duration (X hours). For instance, does adjusting the End Date on a task automatically adjust the start and end dates of any "follows" task recursively?
Updated by Bruno Medeiros about 14 years ago
A lot of people in my company asks for it, definitely start_date != creation_date.
I tried to apply the #2277 patch, but it's old. I will try to adjust it later.
+1
Updated by Jean-Michel Godin almost 14 years ago
I really think the start date should not be added by default. Also if you manually erase it and you create your issue it still the start date still get set so you need to update the issue to remove it.
Updated by Terence Mill almost 14 years ago
IF it would be possible configure per tracker, per role, per status which fields are visible, mandatory (always visible), optional and which position they shall have (eg. field "status" 3rd position left column) you have the freedom to satisfy most of this feature requests, SOme fields come with base install other can be added via custom fields.
Updated by Nicholas Kulikov almost 14 years ago
+1 for any solution that allow disable autofill :)
Updated by Anonymous almost 14 years ago
Eric Davis wrote:
I disagree with automatically adding the start date for different statuses. Status names can be changed by an Administrator and we might not always have a "Assigned" status.
You are right of course, but how about adding a checkbox in the administration of issue stati that says "Reset start date" that you can check only for one status (as in "assigned"). After all, you can also automatically set "% Done", "Default value" and "Issue closed" individually.
Of course, one should be careful with workflows then because it might lead to people resetting the start date if they change the status to that one again during the lifetime of the issue. So it should probably be a "one time setting"...
Just thinking out loud...
Updated by Bruno Medeiros almost 14 years ago
Let's fix bugs first, I created #6575 to address the problem of start date being filled even when mannually erased. I. hope someone fix it soon.
Updated by Mischa The Evil over 12 years ago
- Status changed from New to Closed
- Resolution set to Fixed
Superseded by implemented #2269.
Updated by Anonymous about 11 years ago
Joris Verschoor wrote:
Also, the startdate COULD be enabled for certain statusses. For example:
ASSIGNED -> fill startdate
FIXED/CLOSED -> fill enddate
That possibility is exactly what I was looking for a long time and found no options, no plugins, no patches, no workarounds.
Developers in my team asked me for that just after Redmine was implemented for our projects.
That would significantly improve our workflow.
Is there any way to automatically fill start/due date using dependencies based on other (generic or custom) fields?
Updated by Bruno Medeiros about 11 years ago
Damian Gutkowski wrote:
...
Is there any way to automatically fill start/due date using deependencies based on other (generic or custom) fields?
Not that I'm aware of.
I suggest you to search on the web, and also on redmine.org, and create a new issue if you don't find one asking the same feature. Posting on closed issues is likely to be ignored.
Updated by Anonymous about 11 years ago
It's ok, I have already found solution :)
https://github.com/dkuk/auto_fields
For the newest Redmine it demands some little tinkering but it works as expected.
Updated by Florian Kaiser over 10 years ago
Damian Gutkowski wrote:
It's ok, I have already found solution :)
https://github.com/dkuk/auto_fieldsFor the newest Redmine it demands some little tinkering but it works as expected.
The plugin is no longer working :/
Updated by Anonymous over 10 years ago
yeah, they (the same guys) have created a much better plugin, it's called Luxury buttons.
It costs but it's worth more thant that.
Updated by Olivier Houdas over 10 years ago
- File Option-StartDate.png Option-StartDate.png added
There is now an option for that... (created by solving issue #2269)