Comment 7 for bug 1004416

This seems to be a summary of what we can do to break the editor at the moment. You can start with just this:

Work items:
foo: DONE
hello: TODO
foo: TODO

You can have two work items with the same name but different states (different states optional), but only if you insert them at the same time. To delete either, you must delete both. If you just delete one, both will come back. You can edit the states of each duplicate item individually.

Now this is set up I can add work items for another milestone. This is the editor input:

Work items:
hello: TODO
foo: POSTPONED
foo: TODO

Work items for unlikelyfuture:
visit moon: TODO

It displays as:

Work items:
hello: TODO
foo: TODO
foo: TODO

Work items for unlikelyfuture:
visit moon: TODO

I.e. the duplicate name work items have got the same state somehow. I can change their states though. If I try and create a new duplicate named item under a different milestone, the first duplicate goes away:

Input:

Work items:
hello: TODO
foo: TODO
foo: DONE

Work items for unlikelyfuture:
visit moon: TODO
foo: POSTPONED

Result:

Work items:
hello: TODO
foo: TODO

Work items for unlikelyfuture:
visit moon: TODO
foo: POSTPONED

If I delete "foo: TODO" from the unscheduled work items (above) I get it turning up as a duplicate in the second list:

Work items:
hello: TODO

Work items for unlikelyfuture:
visit moon: TODO
foo: POSTPONED
foo: POSTPONED

So, what is going wrong? It is easy to draw conclusions, but I need to look a little more closely at the code to make sure they are the right ones. I guess one fundamental question is do we want to allow duplicate work items to exist for the same milestone. I can imagine this would make sense if the same task was assigned to two people, but improving the syntax to describe this would be better ([me, you] thing to be done: TODO). That said, without a database re-org, we would have to store separate entries for each person (probably fine) and take care with displaying properly.

The other problem we have here is that this is a text box not really doing the job of a text box and it may be more sensible to replace it with the work item editor that currently exists in extension form: http://voices.canonical.com/michael.hudson/2011/09/01/announcing-the-workitem-editor-greasemonkey-script/

When it comes to what is already in the database, if we don't want duplicate work items we need to get rid of them at some point. We could run a script over the database to delete them (which would be rather scary) or we could modify the LP code to clean-on-display, i.e. when creating the text for the work items box, don't display duplicates and on save, handle cleaning out duplicates properly. I worry about the fact that we could have people already using duplicate work items to assign work to more than one person and just cleaning out duplicates from the database would break their workflow. I think having duplicates assigned to nobody/the same person is wrong though and I can't think of a reason not to clean those out somehow.