Redmine

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 enddate

If start is an indication of when someone should start, you should fill in due-date, and substract estimated-hours/8 = days.

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.

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

Just a new journal to push email updated: Related Patch #2269 can maybe solve the issue for both "camps"...

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?

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

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.

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.

+1 for any solution that allow disable autofill :)

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

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.

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?

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.

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.

Damian Gutkowski wrote:

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.

The plugin is no longer working :/

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.