Launchpad itself

ajax bug assign widget does not update the edit for behind the expander

Bug #734610 reported by Andrew Bennetts
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

On <https://bugs.launchpad.net/bzr/+bug/733350> I just:

1. clicked the “Unassigned” edit icon (in the “Assigned to” column), and assigned that bug to me
2. decided to increase the Importance and add a comment explaining why, so I clicked the little expander arrow at the left of the table row, and set the Importance, added a comment, and clicked “Save changes”
3. upon reloading the bug page the bug was unassigned

I suspect the problem is that the AJAXy goodness for the inline editing of the “Assigned to” cell doesn't update the fields in the form revealed by the expander arrow. Possibly the other fields (Importance, Status, Milestone) have the same issue.

Revision history for this message
Robert Collins (lifeless) wrote :

Another way of thinking about it is that submissions of that form overwrite all fields rather than changing a delta. If we included the original values as hidden fields we could detect unaltered fields and fix this more solidly. Probably we can make the zope form machinery do that.

Changed in launchpad:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Andrew Bennetts (spiv) wrote : Re: [Bug 734610] Re: Commenting on bug task after assigning to me unassigns

Robert Collins wrote:
> Another way of thinking about it is that submissions of that form
> overwrite all fields rather than changing a delta. If we included the
> original values as hidden fields we could detect unaltered fields and
> fix this more solidly. Probably we can make the zope form machinery do
> that.

That wouldn't fix that form displaying the wrong value, though. (Which
I didn't notice in my case until after I'd already submitted the form,
because I naturally wasn't intending to pay attention to that field of
the form.)

Committing a delta from that form, rather than a snapshot, seems more
like a fix for better handling concurrent updates from other requests
than a fix for this bug.

Revision history for this message
Robert Collins (lifeless) wrote :

On Mon, Mar 14, 2011 at 6:24 PM, Andrew Bennetts
<email address hidden> wrote:
> Robert Collins wrote:
>> Another way of thinking about it is that submissions of that form
>> overwrite all fields rather than changing a delta. If we included the
>> original values as hidden fields we could detect unaltered fields and
>> fix this more solidly. Probably we can make the zope form machinery do
>> that.
>
> That wouldn't fix that form displaying the wrong value, though.  (Which
> I didn't notice in my case until after I'd already submitted the form,
> because I naturally wasn't intending to pay attention to that field of
> the form.)

It would show the wrong value but not alter it.

> Committing a delta from that form, rather than a snapshot, seems more
> like a fix for better handling concurrent updates from other requests
> than a fix for this bug.

You are concurrently conflicting with yourself, *and* you are seeing
stale data in the same page. Fixing either will address the issue you
titled this bug with, and fixing the concurrent aspect is more broadly
useful.

-Rob

Robert Collins (lifeless)
summary: - Commenting on bug task after assigning to me unassigns
+ ajax assign widget does not update the hidden form
summary: - ajax assign widget does not update the hidden form
+ ajax bug assign widget does not update the edit for behind the expander
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.