Start Date should not be allowed to be after the End Date

What should be the default behaviour ?

1) We refuse to set a start date after a due date. Logical but not good for user experience.

2) We extend the due date. Fine. But what if the due date is modified afterward ? We refuse it ? Or we always obey to "the last order" ?

This is, AFAIK, not as simple as previously thought.

On Sun, Mar 21, 2010 at 2:43 PM, Lionel Dricot <email address hidden> wrote:
> What should be the default behaviour ?
>
> 1) We refuse to set a start date after a due date. Logical but not good
> for user experience.
>

Why is it "not good for user experience"?

jml

Because, currently, there's no feedback. It simply doesn't work. This is very bad for user experience (equivalent to a broken feature).

If we have some way to provide a feedback, this is still bad because it is "I can't do that Dave", irrating behaviour even if you understand it.

On Sun, Mar 21, 2010 at 3:37 PM, Lionel Dricot <email address hidden> wrote:
> If we have some way to provide a feedback, this is still bad because it
> is "I can't do that Dave", irrating behaviour even if you understand it.

I disagree. We're not talking about opening the pod bay doors, we're
talking about something that's not even logically possible, which
means that every time a user asks for a due date that is before the
start date they are making a mistake. It's like typing "orange" as
your birthday. Make the error message as unobtrusive as possible, but
provide an error message.

I thought it would be possible to disable the gtk.Calendar dates which do not satisfy our limitations (say, gray unselectable dates). Unfortunately, that can't be easily done.

IMO, the way it should work is if the start date is changed to be
after the due date, the due date should be updated to reflect the
start date. Or blank out when the start date is changed to be after
the due date. If the user then changes the due date to reflect
something after the start date, it should act as normal.

On Sun, Mar 21, 2010 at 05:22:44PM -0000, Luca Invernizzi wrote:
> I thought it would be possible to disable the gtk.Calendar dates which
> do not satisfy our limitations (say, gray unselectable dates).
> Unfortunately, that can't be easily done.

That would be the cleanest UI, although it would address only the case
where the user sets the due date via the calendars. This can also be
done via dbus, plugins, or the context menu (by setting a due date in
the past, and then using the context menu to reschedule the task to
start tomorrow).

So, I think fixing it in the calendar widget would only paper over the
issue and incompletely.

I assume everyone agrees that due date before start date is not a valid
condition for a task to be in. So currently this is a core bug.

If we fixed the validation to not permit it to begin with, then while
that makes the UI a little less intuitive, it at least converts a bug in
core to a (less severe imho) UI bug.

I've been experimenting in my own branch to just refuse to change the start date if it would make it after the due date. But I'm finding that to be rather irritating.

One thing I've found is that if a due date is set on a parent task, the child task inherits that due date, and you cannot change the child task to be due later than the parent task. When you have the WorkView turned on, you can't see the parent task, and since you can't change the due date of the child task, it is very unclear what you have to do to move the due date later. And in the case of my branch where you can't change the start date either, the result is there is no way to push the task off the workview (aside from closing the task).

I think the original suggestion of just having gtg move the due date if the start date gets shifted is in fact the right way to go.

If gtg tries to be clever about limiting what the user can do (even such as graying out dates in the calendar), it may merely frustrate them and risk corner cases such as the one I described.

Closing because there is no further discussion and the fix was already committed in rev 839.