Work Items not allowing users to edit them properly

I had this reproduced with a local dev instance. Once I cut out all the work items, OK'd the change, then pasted them back in it was fine. Of course my reproducer has gone now, but that is a work around if nothing else!

The problem is likely the fact that these two work items have identical textual descriptions. Considering the UI (which is a giant text box), description is used as the identifier for a work item, so once there are two work items with identical descriptions, problems are not surprising.

However, I wonder how did we get to a state where we have to identical work items. It could be a race condition, though that doesn't sound very likely.

This occurs for me on blueprints where I have identical work items, but 2 different people assigned. for example,

[nskaggs] Make lots of ponies!
[gema.gomez] Make lots of ponies!

Editing that to change it seems to retain those work items even if I remove them

Same problem in https://blueprints.launchpad.net/ubuntu/+spec/community-q-dev-initiatives

When I change work item data, sometimes it deletes work items or duplicates others.

seeing this behavior also on: https://blueprints.launchpad.net/ubuntu/+spec/other-q-motu-bof

From bug #1012755

On https://blueprints.launchpad.net/linaro-license-protection/+spec/build-info-definition if you change ‘Work items:’ heading to ‘Work items for 2012.06:’, all hell breaks lose (four sections, in order, ‘Work items for 2012.05’, ‘Work items for 2012.06’, ‘Work items’ and ‘Work items for 2012.06’).

I can recreate this in a local instance with different milestone names.

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.

Fixed in stable r15445 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/15445>.