Need persistence for bug listing display widget

Bug #891780 reported by Deryck Hodge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Deryck Hodge

Bug Description

The widget that changes the fields displayed in new bug listings doesn't persist your preferred fields to the next page load. We're planning to use cookies for a kind of light weight persistence. This bug is to track the qa of that work as it lands.

Related branches

Deryck Hodge (deryck)
tags: added: bug-columns
Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 891780] [NEW] Need persistence for bug listing display widget

We already have a session cookie; strongly encourage you to put it
into that state, if you're going down that route - also what
granularity are you working on? e.g. site wide? product wide?

-Rob

Revision history for this message
Deryck Hodge (deryck) wrote :

We're looking at this being product-wide, i.e. just for bugs domain and new bug listings.

Francis mentioned the session cookie, too, but I only need to read and write this from js so wasn't planning on using the session. I'll admit I don't know what we're doing with sessions well, but I assume it's a hash which is read server-side. We don't need persistence through to the view, just something the client-side can see for rendering fields on or off. And it needs to be readable on the client, too.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 891780] Re: Need persistence for bug listing display widget

On Fri, Nov 18, 2011 at 9:55 AM, Deryck Hodge
<email address hidden> wrote:
> We're looking at this being product-wide, i.e. just for bugs domain and
> new bug listings.

global then :) - in that /launchpad and /bazaar will get the same
state - change on one will change on the other?

> Francis mentioned the session cookie, too, but I only need to read and
> write this from js so wasn't planning on using the session.  I'll admit
> I don't know what we're doing with sessions well, but I assume it's a
> hash which is read server-side.  We don't need persistence through to
> the view, just something the client-side can see for rendering fields on
> or off.  And it needs to be readable on the client, too.

The session cookie matches those things; going through the view will
be needed if/when you want the sort to persist, otherwise you will end
up sorting twice - once on initial render and then once when you apply
the remembered sort. Client js can read the session cookie.

-Rob

Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Deryck Hodge (deryck)
tags: added: qa-ok
removed: qa-needstesting
Raphaël Badin (rvb)
Changed in launchpad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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