Merge lp:~deryck/launchpad/field-visibility-persistence-891780 into lp:launchpad
Status: | Merged |
---|---|
Approved by: | Deryck Hodge |
Approved revision: | no longer in the source branch. |
Merged at revision: | 14367 |
Proposed branch: | lp:~deryck/launchpad/field-visibility-persistence-891780 |
Merge into: | lp:launchpad |
Diff against target: |
396 lines (+228/-8) 4 files modified
lib/lp/bugs/browser/bugtask.py (+36/-2) lib/lp/bugs/browser/tests/test_bugtask.py (+27/-2) lib/lp/bugs/javascript/buglisting_utils.js (+70/-2) lib/lp/bugs/javascript/tests/test_buglisting_utils.js (+95/-2) |
To merge this branch: | bzr merge lp:~deryck/launchpad/field-visibility-persistence-891780 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Graham Binns (community) | code | Approve | |
Review via email: mp+83037@code.launchpad.net |
Commit message
[r=gmb][bug=891780] Set a cookie that CustomBugListings can use to update field_visibility of a bug list.
Description of the change
Our new feature CustomBugListings needs to honor changes to field visibility in the listings across page loads. A simple way to achieve this is to set a cookie that stores those prefs. This branch makes a few changes to make that happen:
* js code is updated to set/delete cookies
based on submitting a form overlay
* new tests are written for js to confirm this
* view is updated to check for existence of cookie
and update field_visibility accordingly
* view also has a test added
Robert had some concerns in the bug about using cookies, which we discussed more offline. His concerns were that:
* another cookie might cause request size to be too large
* session cookie might be better than adding a new cookie
I've checked on request size and we're way safe. Nothing to worry about there.
I rejected the session cookie idea initially because I was only reading and writing from js, and js code shouldn't be able to read the session cookie as plain text. Or be able to reverse the hash. I didn't think we needed to understand the cookie on the server side because I thought we hid the first batch we render behind a noscript tag and rendered everything else client side. We do indeed use the first batch rendered on page load, so now the view is involved. I'm happy to revisit this before we're done-done and work out an API that the client can use to submit stuff to the session cookie if this is really required.
I'm still not sure I like this idea, though. Paranoia makes me fear anything other than the server adding something to the session cookie, and I'm also not sure what we gain for that beyond consolidating on a single cookie. There is clearly value in keeping cookie count low, so I can be persuaded, but generally, I think what I have here works fine. I recognize I could be tending toward stubborn old-man refusal here, so I welcome correction if so.
If people feel strongly about going through our session cookie, I'd prefer to land this as it is, assuming the code is okay, and file an XXX to fix this to use our session cookie before we're off the feature.
Hi Deryck,
Nice branch; good work! I've got a few comments but nothing earth
shattering.
[1]
9 + user = getUtility( ILaunchBag) .user
Without looking at the context in more detail I can't be certain, but
typically we should be preferring self.request.user over using the
LaunchBag.
[2]
29 + """Set field_visibility for the page load. fields is found,
30 +
31 +
32 + If a cookie of the form $USER-buglist-
Looks like you have an extra line of blankness here.
[3]
47 + if cookie is not None: from_cookie[ field] = value visibility = fields_from_cookie
48 + for item in cookie.split('&'):
49 + field, value = item.split('=')
50 + if value == 'true':
51 + value = True
52 + else:
53 + value = False
54 + fields_
55 + self.field_
You could save yourself some lines here by using urlparse.parse_qsl,
which returns (key, value) tuples, thus:
for field, value in urlparse. parse_qsl( cookie) :
fields_ from_cookie[ field] = (value == 'true') field_visibilit y = fields_from_cookie
# We only record True or False for field values, so we only care
# about whether the value from the cookie is 'true'.
self.
[4]
138 + /** isValue( window. LP) && Y.Lang. isValue( LP.links) ) {
139 + * Helper method to always get the same cookie name, based
140 + * on user name.
141 + *
142 + * @method getCookieName
143 + */
144 + getCookieName: function() {
145 + var user;
146 + if (Y.Lang.
147 + var me = LP.links.me;
148 + user = me.replace('/~', '');
149 + } else {
150 + user = 'anon';
151 + }
152 + return user + '-buglist-fields';
153 + },
Rather than doing this twice - once in the View and once in the JS - it
would make more sense to do it in the view and then bung it in the page
JS cache so that the JS can just use the value that's already been
calculated.