[User Story] Home screen adapted to operator apps in case of inserting a SIM card after first time usage

VERIFIED FIXED

Status

Firefox OS
Gaia::System
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: sonmarce, Assigned: Carmen Jimenez Cabezas)

Tracking

({feature})

unspecified
ARM
Gonk (Firefox OS)
feature
Dependency tree / graph
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(blocking-b2g:-)

Details

(Whiteboard: [ucid:System10, FT:systems-fe, KOI:P2][systemsfe])

Attachments

(1 obsolete attachment)

(Reporter)

Description

5 years ago
As a BU I want home screen to include Local 3rd party applications the first time to insert a SIM card after first time usage

Acceptance criteria:
* Core and Common 3rd party apps are stored in the build the same way as before
* Local 3rd party apps are stored in the build in a separate location that can be reused
* Build will include a grid configuration per BU (Core, Common 3rd party and Local 3rd party apps)
* Home screen was already configured including Core and Common 3rd party apps
* After installing the SIM card for the first time:
  * BU grid configuration will be selected based on MCC and MNC
  * Local 3rd party apps for the selected BU will be installed together with the other apps
  * Home screen grid will be set up according to BU configuration
  * Apps previously installed by the user will be moved to the end of home screen
  * Storage of Local 3rd party apps not belonging to this BU will be removed to save space
  * No data network connectivity will be needed during the whole process
* Later SIM change or removal imply no change in home screen grid
* Local 3rd party apps can be updated later on the same way as other apps
* Factory reset will keep Local 3rd party apps already installed
(Reporter)

Updated

5 years ago
Blocks: 892938
Keywords: feature
(Reporter)

Comment 1

5 years ago
Probably we have to rearrange the home screen to match configuration defined by the operator, as there can be some agreements with third parties, but for apps installed by the user maybe there are better options than putting them at the end. So, we need UX feedback to improve user experience.
(Assignee)

Updated

4 years ago
Assignee: nobody → cjc
(Reporter)

Comment 2

4 years ago
After receiving feedback from UX, we have to remove following acceptance criteria:
* Home screen grid will be set up according to BU configuration
* Apps previously installed by the user will be moved to the end of home screen
To be replaced by following ones:
* Core and Common 3rd party apps already installed before inserting the SIM card will not be moved
* Any app installed by the user before inserting the SIM card will not be moved
* After inserting the SIM card for the first time, Local 3rd party apps will be installed:
  * Each app should be installed in their configured homescreen & position
  * In case of the position is not free, app will be installed in the first free position of the same homescreen
  * In case of the homescreen is full, app will be installed in the first free position of the next homescreen
(Reporter)

Comment 3

4 years ago
Just to have all the information in a single comment, here is the whole user story, after applying changes in previous comment.

As a BU I want home screen to include Local 3rd party applications the first time to insert a SIM card after first time usage

Acceptance criteria:
* Core and Common 3rd party apps are stored in the build the same way as before
* Local 3rd party apps are stored in the build in a separate location that can be reused
* Build will include a grid configuration per BU (Core, Common 3rd party and Local 3rd party apps)
* Home screen was already configured including Core and Common 3rd party apps
* Core and Common 3rd party apps already installed before inserting the SIM card will not be moved
* Any app installed by the user before inserting the SIM card will not be moved
* After installing the SIM card for the first time:
  * BU grid configuration will be selected based on MCC and MNC
  * Local 3rd party apps for the selected BU will be installed together with the other apps:
    * Each app should be installed in their configured homescreen & position
    * In case of the position is not free, app will be installed in the first free position of the same homescreen
    * In case of the homescreen is full, app will be installed in the first free position of the next homescreen
  * Storage of Local 3rd party apps not belonging to this BU will be removed to save space
  * No data network connectivity will be needed during the whole process
* Later SIM change or removal imply no change in home screen grid
* Local 3rd party apps can be updated later on the same way as other apps
* Factory reset will keep Local 3rd party apps already installed
Noemi Freire changed story state to started in Pivotal Tracker
(Reporter)

Comment 5

4 years ago
We need this for preloaded apps to be configured for each country when SIM card is inserted in case of not available during first time the device is powered on
blocking-b2g: --- → koi?
(Reporter)

Updated

4 years ago
Depends on: 893800
Whiteboard: [ucid:System10, FT:systems-fe, KOI:P1]

Updated

4 years ago
Whiteboard: [ucid:System10, FT:systems-fe, KOI:P1] → [ucid:System10, FT:systems-fe, KOI:P1][systemsfe]
Whiteboard: [ucid:System10, FT:systems-fe, KOI:P1][systemsfe] → [ucid:System10, FT:systems-fe, KOI:P2][systemsfe]
(Assignee)

Comment 6

4 years ago
This bug has been resolved in bug 893800
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
Carmen Jimenez Cabeza changed story state to delivered in Pivotal Tracker
Carmen Jimenez Cabeza changed story state to accepted in Pivotal Tracker
Switching this to be fixed by bug 893800 instead of works for me.
Keywords: verifyme
QA Contact: jsmith
Resolution: WORKSFORME → FIXED

Updated

4 years ago
blocking-b2g: koi? → koi+

Updated

4 years ago
QA Contact: jsmith
(Assignee)

Comment 10

4 years ago
After our QA verified this, it seems that apps are installed on the desired place even when the sim wasn't present at boot time, which isn't correct. Reopening it
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

4 years ago
Keywords: verifyme
Carmen, what needs to happen next here? Are you going to fix this?

The release management team is targeting *tomorrow* to freeze the last of features landing, so need to determine action here quickly.

Thanks!
Flags: needinfo?(cjc)
(Assignee)

Comment 12

4 years ago
Created attachment 807289 [details]
Install the apps at the end of their desired screen or the first screen after that with space when the SIM isn't present at first boot
Attachment #807289 - Flags: review?(fernando.campo)
Attachment #807289 - Flags: review?(crdlc)
(Reporter)

Comment 13

4 years ago
Dietrich, this US was already landed last week, but our QA team detected a bug this week, and this is the reason why we reopened the bug. We can open a new bug if it is required, and close this bug as it was before...
(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #13)
> Dietrich, this US was already landed last week, but our QA team detected a
> bug this week, and this is the reason why we reopened the bug. We can open a
> new bug if it is required, and close this bug as it was before...

In that case, a new bug is probably a better idea. This bug is tracking feature completion, not a bug in the feature.
During partner discussions in Oslo, we indicated that we would really like this in Koi, but if it does not make it, we would not block the release on it.  Marking non-blocking.
blocking-b2g: koi+ → -
(Assignee)

Updated

4 years ago
Depends on: 918432
(Assignee)

Comment 16

4 years ago
Opening the bug on a follow up at bug 918432. Leaving this as it was
(Assignee)

Updated

4 years ago
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Flags: needinfo?(cjc)
Resolution: --- → FIXED
(Assignee)

Updated

4 years ago
Attachment #807289 - Attachment is obsolete: true
Attachment #807289 - Flags: review?(fernando.campo)
Attachment #807289 - Flags: review?(crdlc)
(Reporter)

Comment 17

4 years ago
Asking for koi? again, as it was landed last week together with bug 893800, sorry for the misunderstanding
blocking-b2g: - → koi?
(Assignee)

Comment 18

4 years ago
(In reply to Dietrich Ayala (:dietrich) from comment #11)
> Carmen, what needs to happen next here? Are you going to fix this?
> 
> The release management team is targeting *tomorrow* to freeze the last of
> features landing, so need to determine action here quickly.
> 
> Thanks!

I already have a patch ready, including the additional tests. I moved it to the follow up bug, and requested approval-gaia-1.2. Sorry for not answering earlier, I was preparing the patch.
(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #17)
> Asking for koi? again, as it was landed last week together with bug 893800,
> sorry for the misunderstanding

I think Peter's argument still holds above comment 15 - not a blocker. It just so happens this did make feature complete, but it's a non-blocking feature that made that date.
blocking-b2g: koi? → -

Updated

4 years ago
Blocks: 918432
No longer depends on: 918432
(Reporter)

Comment 20

4 years ago
Peter, this US was finished before feature freeze, so this US must be koi+ as it was before. Now we are testing US and detecting bugs that we have to fix, and we will ask for the right flag to be triaged.
Flags: needinfo?(pdolanjski)
(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #20)
> Peter, this US was finished before feature freeze, so this US must be koi+
> as it was before. Now we are testing US and detecting bugs that we have to
> fix, and we will ask for the right flag to be triaged.

Making feature freeze for a non-blocking feature does not make an argument to block. We have nice to have & strongly have features that will make this date as well, but that doesn't justify turning them into blockers. This feature should ride the trains and if it meets a quality bar acceptable to product, will ship in 1.2. If not, the feature will be preffed off.
(Reporter)

Comment 22

4 years ago
I do not want to start a discussion, just summarize what happened here. This US was finished before feature complete on Sept 16th. It was not needed to land any patch, because after landing bug 893800, we got the expected behavior. So we just closed this US, and that was all.

This week our QA team detected a bug related to this US, so we had to create a new bug or reopening this one. As this bug did not have any patch, we thought the best option was to reopen this bug. Then, you told us that this is not the way to proceed, so we created a new bug and removed the patch from this bug.

Now we should be in the same situation as before comment 10: US finished before feature freeze, marked as koi+, as it a must have for 1.2, according to Google spreadsheet.
(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #22)
> Now we should be in the same situation as before comment 10: US finished
> before feature freeze, marked as koi+, as it a must have for 1.2, according
> to Google spreadsheet.

First, sorry for the confusion.

I think the Google spreadsheet not up to date with user story priority - the bug here is, which is why Peter made the comment above when he minused this user story. See:

[ucid:System10, FT:systems-fe, KOI:P2]

KOI:P2 means this is not a blocking feature for release - P1 is a blocking feature. That doesn't mean this isn't going into 1.2 - it made feature freeze, so it's actively riding the trains to 1.2. If it meets an acceptable quality bar deemed by QA & Product, then that feature can ship on 1.2. That's why this is blocking- - it's just specifying that this moved to being a non-blocking feature 1.2, even though it is implemented for 1.2 right now.

We can discuss this more when we have another System FE coordination-like meeting (e.g. triage).
If this is breaking anything.  Then we should back it out regardless if it landed last week and plan on it getting into 1.3. We are not going to hold 1.2 back in order to wait for the additional fix.
(In reply to Candice Serran from comment #24)
> If this is breaking anything.  Then we should back it out regardless if it
> landed last week and plan on it getting into 1.3. We are not going to hold
> 1.2 back in order to wait for the additional fix.

This isn't breaking anything... It's just a case that doesn't work as expected, and that has a working fix already (waiting for review) on bug 918432. Even without landing that patch, this problem happens only on devices that have both been configured for single variant and for not requiring the SIM at first use (and then only if the SIM isn't present anyway). I think that mainly TEF is going to launch single variant devices for 1.2, and that we most definitely are going to require the SIM a boot time, so it should not be an issue, even if we didn't patch it (which we already have anyway).

Anyway there's something I don't understand about this. AFAIK we've passed feature complete already... but we can still fix bugs that are found during these weeks on the features that have landed, can't we? Which is just the case here. Marking this as blocking or not blocking now is a academic discussion mostly since as Jason pointed before, the feature is in 1.2.

Updated

4 years ago
QA Contact: rafael.marquez

Updated

4 years ago
Flags: in-moztrap?(rafael.marquez)

Updated

4 years ago
Keywords: verifyme
Depends on: 922585
(Reporter)

Updated

4 years ago
No longer blocks: 918432
Depends on: 918432
Flags: needinfo?(pdolanjski)

Updated

4 years ago
Depends on: 935437

Updated

4 years ago
Depends on: 935924

Updated

4 years ago
Depends on: 939342

Updated

4 years ago
No longer depends on: 939342

Updated

4 years ago
Status: RESOLVED → VERIFIED

Updated

4 years ago
Keywords: verifyme
https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2508
Flags: in-moztrap?(rafael.marquez) → in-moztrap+
You need to log in before you can comment on or make changes to this bug.