Closed Bug 911958 Opened 7 years ago Closed 7 years ago
.me][feature] Configurable collections order by operators in build time
No description provided.
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Now that Evme Collections are another type of grid icons, it should be possible to configure them in the manner that apps are configured
Attachment #800080 - Attachment description: 11948.html → Patch v1
Attachment #800080 - Flags: review?(ran) → review+
Comment on attachment 800080 [details] Patch v1 I'm fine with the patch but please do not call the collection file manifest.webapp since those are not really webapps. Can I suggest collection.manifest?
Attachment #800080 - Flags: review?(21) → review+
Got it, I am totally agree, thanks for the suggestion Vivien
Ran, could you clarify what this patch allows for? Does it cover the following scenarios? 1) A partner who wants to ship with no smart collections on the homescreen (user could still add them later) 2) A partner who wants to configure how many smart collections they have, what grid positions they are in and which collections are used
All those scenarios are covered indeed.
(In reply to Peter Dolanjski [:pdol] from comment #5) > Ran, could you clarify what this patch allows for? Does it cover the > following scenarios? > > 1) A partner who wants to ship with no smart collections on the homescreen > (user could still add them later) This patch allows partners to do this > 2) A partner who wants to configure how many smart collections they have, > what grid positions they are in and which collections are used This patch allows partners to set up what collections are used and the positions of them like apps
Ran/Cristian, thanks for the clarification.
This is critical for the release to ensure configuration options are in place. Marking blocking.
blocking-b2g: koi? → koi+
Agree, we need this for release. Thanks.
Comment on attachment 808419 [details] Patch - redirect to github PR Please Ran move to this review to bug 910331
Comment on attachment 808419 [details] Patch - redirect to github PR My mistake , this is the correct bug, sorry
Attachment #800080 - Attachment is obsolete: true
Comment on attachment 808582 [details] Patch - redirect to github PR.html The review was done here https://github.com/EverythingMe/gaia/pull/11 All comments were addressed so waiting for Travis
Attachment #808582 - Flags: review?(crdlc) → review+
Attachment #808582 - Flags: feedback?(kgrandon)
Comment on attachment 808582 [details] Patch - redirect to github PR.html Reviewed the regex change and looks good to me.
Attachment #808582 - Flags: feedback?(kgrandon) → feedback+
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I was not able to uplift this bug to v1.2. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1.2, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1.2 git cherry-pick -x -m1 d90878009b4d864e690b0d382f33a781f1ed0bc1 <RESOLVE MERGE CONFLICTS> git commit
Depends on: 910316
It depends on bug 910316
Per a recent release drivers discussion, we need to hold off on uplifting this to 1.2 until we confirm a path forward post the planned e.me 1.2 status meeting tomorrow.
Clearing nom - we're no longer taking e.me 1.2 feature changes to 1.2.
blocking-b2g: koi+ → ---
This is important to deliver when we have collections. Nom'ing for 1.3.
blocking-b2g: --- → 1.3?
This is targeted feature for 1.3, not committed, so we don't need to block on this.
blocking-b2g: 1.3? → -
You need to log in before you can comment on or make changes to this bug.