Closed
Bug 574290
Opened 14 years ago
Closed 14 years ago
[EB] Implement "Add to Collection" interaction on the add-on details page
Categories
(addons.mozilla.org Graveyard :: Collections, defect, P1)
addons.mozilla.org Graveyard
Collections
Tracking
(Not tracked)
VERIFIED
FIXED
5.11.8
People
(Reporter: clouserw, Assigned: davedash)
References
Details
(Whiteboard: [Q32010])
One of the new links on the Add-on details page is "Add to Collection." See location and layout on these mockups: http://people.mozilla.com/~chowse/drop/amo/electric-bandwagon/v1/Addon_Details.png http://people.mozilla.com/~chowse/drop/amo/electric-bandwagon/v1/Persona_Details.png http://people.mozilla.com/~chowse/drop/amo/electric-bandwagon/v1/Interactions_Directories.png And see the interaction flow here: http://people.mozilla.com/~chowse/drop/amo/electric-bandwagon/v1/Interactions.png This bug is for the full implementation of this widget on detail pages and on listing pages. Remember scalability was an issue when dealing with this widget in remora. Don't forget unit tests for things like "This add-on is already in the collection, show it as checked." See the spec for details, section "Add-on Details page": https://docs.google.com/Doc?docid=0Acwo2Bn17-PrZGZudHRobnJfNjVjYnFqMm5kZw&hl=en
Reporter | ||
Updated•14 years ago
|
Target Milestone: --- → 5.11.5
Reporter | ||
Updated•14 years ago
|
Assignee: nobody → dd
Assignee | ||
Comment 1•14 years ago
|
||
In what way was this a scaling issue for remora? For most people it'll show the login prompt, for the logged in people we should be able to power this all via AJAX.
Reporter | ||
Comment 2•14 years ago
|
||
The scaling problem came from us showing all the user's collections, and then taking out any collections that the add-on was already a part of. It looks like we're doing the same thing here, so we just need to make sure that query is as fast as it can be. Loading this via ajax wfm.
Assignee | ||
Comment 3•14 years ago
|
||
Code is being reviewed by potch, and then will be styled by him too: http://github.com/davedash/zamboni/tree/addon-collections-574290 I might use event delegation to avoid re-attaching handlers, but I haven't decided yet.
Reporter | ||
Updated•14 years ago
|
Target Milestone: 5.11.5 → 5.11.6
Reporter | ||
Comment 4•14 years ago
|
||
This is pretty much done, but needs styling.
Target Milestone: 5.11.6 → 5.11.7
Reporter | ||
Updated•14 years ago
|
Target Milestone: 5.11.7 → 5.11.8
Assignee | ||
Comment 5•14 years ago
|
||
http://github.com/jbalogh/zamboni/commit/37104c0
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Flags: in-testsuite?
Flags: in-litmus?
Comment 6•14 years ago
|
||
We disabled this on both preview/next, where it wasn't doing anything (404s).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 7•14 years ago
|
||
was zamboni serving these urls?
Comment 8•14 years ago
|
||
(In reply to comment #7) > was zamboni serving these urls? No. We blocked this code with the NEW_COLLECTIONS flag since we can't run the EB collection migrations on prod and I don't know how the backend will work without it. QA: There's nothing broken about this bug. We just need to flip NEW_COLLECTIONS to get it back.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Updated•8 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•