Closed
Bug 894644
Opened 12 years ago
Closed 11 years ago
API consumers should be able to reorder collections on a region/page pair
Categories
(Marketplace Graveyard :: API, defect, P4)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: chuck, Unassigned)
References
Details
From the publishing tool, publishers will be able to add an arbitrary number of collections and featured applications to a region (country + operator)/page (category + homepage) pair.
To do this, we need an endpoint that allows users to reorder collections on a region/page pair.
This endpoint should be protected by the Apps:Publisher permission created in bug 894425.
Reporter | ||
Updated•12 years ago
|
Assignee: nobody → charmston
Reporter | ||
Updated•12 years ago
|
Assignee: charmston → mpillard
Updated•12 years ago
|
Summary: API consumers should be able to remove reorder collections on a region/page pair → API consumers should be able to reorder collections on a region/page pair
Comment 1•11 years ago
|
||
When you know more about how this will work, can you let me know?
Comment 2•11 years ago
|
||
I feel like, since we put region/category/carrier as a field directly on Collection model, we could do the same for `order`. If you want to have the same collection appear in multiple places, you'd have to clone it anyway to use a different region/category/carrier, so it's not a problem if the order field lives on the Collection model, IMHO.
What do you guys think? Not sure yet how the API would look, probably very similar as the one we have to order/re-order apps inside a Collection ?
Comment 3•11 years ago
|
||
The problem with order is if you have a scenario like this:
Collection 1:
- No region specified
- "order": 1
Collection 2:
- Region X
- "order": 2
Collection 3:
- Region X
- "order": 3
All three collections should show for region X (null region implies all regions). But only Collection 1 would show for any other region. The order should be unique to the category/region.
Perhaps we need a model that look like this:
CatRegionCollectionList:
- Category (null=true)
- Region (null=true)
- List of IDs (?)
Not sure how to do the list of IDs. Maybe a normalized JSON blob? I'm not sure that it's a great plan to have a many-to-many model for this for the sake of performance.
Either way, though, I don't think there's any good way of going about this without having a separate model to represent the order.
Comment 4•11 years ago
|
||
I'm having some trouble representing this in my mind, so requesting some clarifications:
Let's say we do it this way. It means sending a POST to some endpoint with:
{
"region": x,
"carrier": y,
"category": z,
"collections": [a, b, c, d]
}
It stores it in a json list in a model with the region/carrier/category fields,
called CollectionsOrdering. When fetching, we use the filters given
(region/carrier/category), fetch corresponding CollectionsOrdering instance.
Then, fetch the collections matching the filters... and this is where we start
having a problem: 1) How do we handle Collections that match the filters but are
not specified in the corresponding CollectionsOrdering instance? This can
happen if a collection was added to a region/carrier/category without touching
the order. Should we display that Collection ? With what order ?
Also, 2) how do we handle Collections that don't match the filters but are
mentionned in the order list ? Ignore them ?
And 3) should the reorder endpoint check that the specified Collections match
the region/carrier/category we are sending ?
4) The one thing I'm still having trouble with is the null-enables-all. I'm not sure when
we are going to have NULL values in the CollectionsOrdering.
Comment 5•11 years ago
|
||
Let me think about this for a bit.
My preliminary thoughts:
- If a collection doesn't match the filters, it should be ejected from the list.
- If the collection matches the filters but isn't in the list, it should be appended to the end.
The CollectionOrdering objects shouldn't be hard objects that are updated in parallel with the collections. I feel like they should just be guidelines for ordering. In a way, I'd say they should be kind of "ephemeral". If one doesn't exist but it should, it should be created on the fly. I.e.: we shouldn't use them as a source of truth for a list of collections, we should get the list of collections and then look to the CO objects for the order.
As for NULL-ables, we should allow the ordering to contain any collections that we'd show to the user. So if the filters are region=X&carrier=Y&cat=Z, a collection that's {region: null, carrier: null, cat: "Z"} should indeed be included.
Comment 6•11 years ago
|
||
Best to reassign this bug to someone else since I'm dealing with other Collections API related stuff at the moment and haven't had the time to make any progress on this one.
Assignee: mpillard → nobody
Comment 7•11 years ago
|
||
We can probably deprioritize it anyway, since it's not needed for launch.
Updated•11 years ago
|
Priority: P2 → P4
Comment 8•11 years ago
|
||
I'm going to WONTFIX this, since with the feed being right around the corner, this likely won't ever even see the light of day.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•