Merge lp:~danilo/launchpad/bug728370-descriptions into lp:launchpad
Status: | Merged |
---|---|
Approved by: | Данило Шеган |
Approved revision: | no longer in the source branch. |
Merged at revision: | 12835 |
Proposed branch: | lp:~danilo/launchpad/bug728370-descriptions |
Merge into: | lp:launchpad |
Prerequisite: | lp:~danilo/launchpad/bug728370-direct-subs |
Diff against target: |
315 lines (+171/-20) 4 files modified
lib/lp/bugs/javascript/subscription.js (+57/-7) lib/lp/bugs/javascript/tests/test_subscription.js (+80/-1) lib/lp/bugs/templates/bug-subscription-list.pt (+20/-3) lib/lp/registry/javascript/structural-subscription.js (+14/-9) |
To merge this branch: | bzr merge lp:~danilo/launchpad/bug728370-descriptions |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gavin Panella (community) | Approve | ||
Review via email: mp+57656@code.launchpad.net |
Commit message
[r=allenap][bug=728370][incr] Make bug subscription descriptions nicer and collapse all the non-direct non-personal along with structural subscriptions into "other subscriptions" box. You do what?
Description of the change
= Bug 728370: prettyfication =
This branch prettyfies the listing of bug subscriptions on a single bug +subscriptions page. So far, we've only rendered all the potential descriptions one below the other, and this branch puts each one of them inside a separate box similar to the boxes structural subscriptions are in.
Follow-up work will introduce actions inside these "boxes" (such as "unsubscribe this team from duplicate bug").
== Implementation details ==
We are not touching structural subscriptions, other than putting them inside the "other subscriptions" slide-out box. This uncovered a few subtle annoyances in structural-
In the change itself, we only extend get_other_
== Tests ==
lib/lp/
lib/lp/
== Demo and Q/A ==
See https:/
https:/
To facilitate the demo:
- set 'malone.
on https:/
- add a few structural subscriptions to firefox using
https:/
- add a few structural subscriptions for firefox package using
https:/
- make bug #2 duplicate of #1, subscribe one of your teams to #2
- subscribe yourself to bug #1
...
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
Wow, the subscriptions stuff is looking *awesome* these days.
This branch looks good. I have a few comments, but nothing major.
[1]
+ var header_link = Y.Node. create( '<a></a> ')
+ .set('href', '#')
Is this needed? Ah, maybe for IE?
[2]
+ Y.Assert. areNotSame(
+ undefined,
Y.Assert. isNotUndefined( ) is slightly more concise.
[3]
+ var node = module. _get_other_ descriptions_ node(info) ; '#other- subscriptions- header a'); '#other- subscriptions- list');
+ var link = node.one(
+ var list = node.one(
IDs are /meant/ to be unique in the page so you could skip the first
line above and just use Y.one().
[4]
+ this.wait( function( ) { function( ) {
[...]
+ this.wait(
[...]
+ }, 500);
+ }, 500);
Are these delays long enough? How long is the animation meant to take?
[5]
- ss_module. setup_bug_ subscriptions( subscription- content- box"});
info_module. show_subscripti on_description(
{descripti on_box: "#subscription- description- box"}); ady', function() { setup_bug_ subscriptions( subscriptions- list"}) ; subscriptions- list');
- {content_box: "#structural-
});
+ Y.on('contentre
+ ss_module.
+ {content_box: "#other-
+ }, '#other-
http:// developer. yahoo.com/ yui/3/examples/ event/event- timing. html
seems to suggest that it's not safe to modify the DOM until domready
fires:
The 'contentready' event fired for the element tainer' . That element and all of its children are
'contentCon
present in the DOM.
The 'domready' event fired. The DOM is now safe to modify via
script.
setup_bug_ subscriptions( ) calls at least one function that modifies
the DOM, so I suspect this change should be reverted.
[6]
+ content_node = content_ node.one( '#overlay- container' );
Like before, and in a few other places, you can just use Y.one() here,
not that it matters much.
Becauase IDs are, afaik, meant to be unique in a DOM tree, I dislike
them; they're like the global variables of the DOM, and I try to avoid
using them, especially in widgets. Do you have any opinions either
way, or are you aware of anyone else's?