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

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.

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

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

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

This bug has been resolved in bug 893800

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.

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

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!

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.

Opening the bug on a follow up at bug 918432. Leaving this as it was

Asking for koi? again, as it was landed last week together with bug 893800, sorry for the misunderstanding

(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.

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.

(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.

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.