1119735 - [FFOS7715 v2.1]Need to added the apns in 'ril.data.cp.apns' into the settings apnlist

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[jinghua.xing]

When we got more than one apns with same type from one oma CP message, we added the apns into the the 'ril.data.cp.apns' settings and put the last apn into 'ril.data.apnSettings' settings, then we go to settings to look at the apn list. We found only the last apn is added into the apn list and we can't find the other. Only after we press the reset to default button, the apns are showed on the apn list together. I think the first time we have not showed the apns stored in 'ril.data.apnSettings' settings in apn list.

Comment 1

[jinghua.xing]

Vance:

I think this issue is very serious, could you help to find someone to help to check this issue?

Thank you

Comment 2

[jinghua.xing]

Arthur：

Can you help me to check this issue and find why the apns in 'ril.data.apnSettings' didn't loaded into the apn list?

Thank you.

Comment 3

[Arthur Chen [:arthurcc][inactive after 6/30]]

We did not expect to have multiple apns in the client provisioning message. Flag as tracking-b2g to have priority working on it.

Comment 4

[jinghua.xing]

Arthur：

I have tried to solve this issue and tried to use the codes below to save the apns newly added to settings

--- a/apps/wappush/js/store.js
+++ b/apps/wappush/js/store.js
@@ -118,6 +118,16 @@ var StoreProvisioning = (function() {
         transaction.set(data);
 
         iccCardIndex = iccCardIndex || 0;
+
+        asyncStorage.getItem('apn.list'+iccCardIndex, function(value) {
+          console.log("WAPPUSH: APN LIST IS "+JSON.stringify(value));
+          if(!value) {
+            value = [];
+          }
+          value = value.concat(parameters);
+          asyncStorage.setItem('apn.list'+iccCardIndex, value);
+        });
+
         var request = transaction.get('ril.data.apnSettings');
         request.onsuccess = function() {
           var apnSettings = request.result['ril.data.apnSettings'];

In settings, we use the apns stored in ‘apn.list’+serviceId to make the apn list and it contains the apns from apn.json and the apn newly added to apnsettings. But when I try to read this in wappush using the code upon, nothing has been read, and it is null.

What is your opinion about this issue? Thank you.

Comment 5

[Arthur Chen [:arthurcc][inactive after 6/30]]

Async storage is per app, so the apn list is not accessible in the wap push app. The design, storing the apn list in the async storage avoids the pollution to the settings db. A possible solution would be adding the apns stored in 'ril.data.cp.apns' to the apn list when deriving the active apn from 'ril.data.apnSettings'.

Comment 6

[jinghua.xing]

Arthur

But I think if we add the apns stored in 'ril.data.cp.apns' to the apn list, we need to find which apns are newly added, if don't do this, the apn list may contains the cp apns which we have deleted or changed before. How can we solve this issue? 

Thank you

Comment 7

[jinghua.xing]

In OMA-WAP-TS-ProvCont-V1_1-20090728-A

It says the TO-NAPID Parameters for PXPHYSICAL characteristic can occur 1 or more times in a PXPHYSICAL characteristic, and the PXPHYSICAL characteristic can also occur 1 or more times in PXLOGICAL characteristic, and the PXLOGICAL characteristic can occur occur 0 or more times. This TO-NAPID parameter refers to a network access point with a matching NAPID parameter, so there can be more than one apns in one document in the client provisioning message.

So I think it is very important for us to support for the client provisioning message with  multiple apns.

Comment 8

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Shawn, Steven

According to the Comment#7, it seems like it is mandatory for device to support provisioning message with multiple APNS. Could you help to check? if you all agree with Comment#7 is correct, please assign someone to work on this

Thanks

Comment 9

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Nominate for now due to it might be a OMA spec requirements

Comment 10

[ffos_st]

HI Vance Chen

There is a solution for the issue.

please check !

diff --git a/apps/wappush/js/parsed_doc.js b/apps/wappush/js/parsed_doc.js
index 330b7f9..f2162c2 100644
--- a/apps/wappush/js/parsed_doc.js
+++ b/apps/wappush/js/parsed_doc.js
@@ -127,10 +127,12 @@
         }
 
         obj['TO-NAPID'] = [];
-        var toNapIdNode = pxPhysicalNode.querySelector('parm[name="TO-NAPID"]');
-        if (toNapIdNode) {
-          obj['TO-NAPID'].push(toNapIdNode.getAttribute('value'));
-        }
+
+        var toNapIdNodeS = pxPhysicalNode.querySelectorAll('parm[name="TO-NAPID"]');
+        for (var j = 0; j < toNapIdNodeS.length; j++) {
+            var toNapIdNode = toNapIdNodeS[j];
+               obj['TO-NAPID'].push(toNapIdNode.getAttribute('value'));
+          }
 


--- a/apps/wappush/js/store.js
+++ b/apps/wappush/js/store.js
@@ -139,8 +139,10 @@ var StoreProvisioning = (function() {
             if (!apnEnabled) {
               apnList.push(apn);
             }
+                 apnSettings.push(apn);
           });
 
thank you 
duzc.

Comment 11

[ffos_st]

HI Vance Chen

There is additional instructions for comment 10.

--- a/apps/wappush/js/parsed_doc.js
+++ b/apps/wappush/js/parsed_doc.js

The Modify is about receiving multi-OTA message .


--- a/apps/wappush/js/store.js
+++ b/apps/wappush/js/store.js

The Modify is to save multi-OTA message in 'ril.data.apnSettings'.

please  confirm that the modify is right ?

thanks 

duzc.

Comment 12

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Gabriele, Arthur, our partner propose a patch for this issue, could you help to check if it is feasible?

Thanks

Comment 13

[Arthur Chen [:arthurcc][inactive after 6/30]]

The original implementation was to make settings app the only app who can manipulate apn lists. Following the idea we could create a new settings field storing newly added cp apns. When displaying apn lists in settings app, we check if there are newly added cp apns. If yes, we add them to the apn list and clear the settings field. This would be the simplest solution but may be considered as abusing of the settings db.

The other option would be maintaining a datastore for apn lists, so both the wap push app and the settings app can manipulate apn lists. Implementing this solution requires more resources.

Comment 14

[Arthur Chen [:arthurcc][inactive after 6/30]]

(In reply to ffos_st from comment #10)
> HI Vance Chen
> 
> There is a solution for the issue.
> 
> please check !
> 
> diff --git a/apps/wappush/js/parsed_doc.js b/apps/wappush/js/parsed_doc.js
> index 330b7f9..f2162c2 100644
> --- a/apps/wappush/js/parsed_doc.js
> +++ b/apps/wappush/js/parsed_doc.js
> @@ -127,10 +127,12 @@
>          }
>  
>          obj['TO-NAPID'] = [];
> -        var toNapIdNode =
> pxPhysicalNode.querySelector('parm[name="TO-NAPID"]');
> -        if (toNapIdNode) {
> -          obj['TO-NAPID'].push(toNapIdNode.getAttribute('value'));
> -        }
> +
> +        var toNapIdNodeS =
> pxPhysicalNode.querySelectorAll('parm[name="TO-NAPID"]');
> +        for (var j = 0; j < toNapIdNodeS.length; j++) {
> +            var toNapIdNode = toNapIdNodeS[j];
> +               obj['TO-NAPID'].push(toNapIdNode.getAttribute('value'));
> +          }
>  
> 
> 
> --- a/apps/wappush/js/store.js
> +++ b/apps/wappush/js/store.js
> @@ -139,8 +139,10 @@ var StoreProvisioning = (function() {
>              if (!apnEnabled) {
>                apnList.push(apn);
>              }
> +                 apnSettings.push(apn);

This won't work as gecko selects the last apn item when receiving multiple ones for the same type. 

>            });
>  
> thank you 
> duzc.

Comment 15

[jinghua.xing]

Arthur:

As our design, the cp apns is stored in 'ril.data.cp.apns' due to the mcc and mnc of the card received the cp message and it is available to all the cards having the same mcc and mnc. But as the solution for this issue in comment13, if the two sim cards in a devices are in same mcc and mnc, one received a CP message and the newly added apns is added into the new settings field, and we first look at the apn list for sim1, the apns are added to the apn list and the settings field is cleared. After doing this, the cp apns can not be available again for the sim2 only if we click the reset to default button. 

Should we take this into consider? Thank you.

Comment 16

[jinghua.xing]

If we do not need to take this into consider, should we store the newly added apns into the new settings field due to the cardindex or the mcc and mnc?

Comment 17

[jinghua.xing]

Arthur:

Can you help to handle this issue as we should take a variety of things into account? Thank you.

Comment 18

[jinghua.xing]

Arthur:

I think we can store the newly apns according to both the cardindex and the mcc mnc. I will workout a patch for the wappush app soon, but as I have not know well about the settings, can you help me to complete the modification of settings?

Thank you.

Comment 19

[siiaceon]

Thanks for Arthur's support.
Because our PTR deadline is close, so we thinkout a quick solution. maybe it isnot a workaround. Because:
1.Setting need SIM index and Operator information.
2.Original DB just store the Operator information.
3.So we need a transfer which fit for Setting needs.

So our action is:
1. modify the "transfer" by jinghua.
2. could you help us modify the setting following this solution or what is your opinion for quick solution?

Thanks for your understanding.

Jinghua, thanks to show out the structure for your "transfer" information.

Comment 20

[jinghua.xing]

Attachment: wappush_multi_apns.patch

Arthur:

This is the patch I made for the wappush app. I add a property "ril.newly.cp.apns" to store the newly added apns according to its iccCardIndex and mcc-mnc. Please help me review it and complete the change in settings app. 

Thank you.

Comment 21

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8551569 [details] [diff] [review]
wappush_multi_apns.patch

Review of attachment 8551569 [details] [diff] [review]:
-----------------------------------------------------------------

As I am not qualified for reviewing the code of the wappush app, redirect the request to Gabriele, but the code looks okay.

Gabriele, for this time being we would like to go for the first solution proposed in comment 13, in which we save the newly received apns that are not committed to the apn lists maintained by settings app. Would you mind take a look at this patch? Thanks.

::: apps/wappush/js/store.js
@@ +118,2 @@
>          transaction.set(data);
>  

Please add comments describing the settings field and its purpose.

@@ +118,4 @@
>          transaction.set(data);
>  
>          iccCardIndex = iccCardIndex || 0;
> +        var newlyApn = transaction.get('ril.newly.cp.apns');

To avoid confusion, let's use "pendingApnsRequest" instead of "newlyApn" as it is actually a request.

@@ +119,5 @@
>  
>          iccCardIndex = iccCardIndex || 0;
> +        var newlyApn = transaction.get('ril.newly.cp.apns');
> +        newlyApn.onsuccess = function() {
> +          var apnResult = newlyApn.result['ril.newly.cp.apns'];

Suggest to use "pendingApns".

@@ +120,5 @@
>          iccCardIndex = iccCardIndex || 0;
> +        var newlyApn = transaction.get('ril.newly.cp.apns');
> +        newlyApn.onsuccess = function() {
> +          var apnResult = newlyApn.result['ril.newly.cp.apns'];
> +          if (!apnResult || !Array.isArray(apnResult)) {

We could remove the checks when specifying the default value as an array in common-settings.json.

@@ +123,5 @@
> +          var apnResult = newlyApn.result['ril.newly.cp.apns'];
> +          if (!apnResult || !Array.isArray(apnResult)) {
> +            apnResult = [{}, {}];
> +          }
> +          var apnNewly = apnResult[iccCardIndex];

As you mentioned, we should append the received apns to both arrays.

::: build/config/common-settings.json
@@ +177,4 @@
>     "ril.cellbroadcast.disabled": [false, false],
>     "ril.data.apnSettings": "",
>     "ril.data.cp.apns": "",
> +   "ril.newly.cp.apns": "",

nit: It would be better to keep the `ril.data` prefix. How about "ril.data.pending.cp.apns"?

And suggest to use [null, null] as the default value.

Comment 22

[jinghua.xing]

Attachment: wappush_multi_apns.patch

I have made some changes to the patch of wappush app. Thanks for Authur's kindly advices. 

Gabriele,Can you help me to review this patch? Thanks.

Comment 23

[siiaceon]

Thanks Arthur. How about the Setting part modification?

with this solution, in case of two SIM with same operator, when the operator push to each SIM , we will find  same redundance information for one SIM in setting. But for quick solution, maybe the custmer can accept it.

Thx

Comment 24

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: WIP for settings app

Jinghua, could you help try if the patch works with yours? Thanks!

Comment 25

[jinghua.xing]

(In reply to Arthur Chen [:arthurcc] from comment #24)
> Jinghua, could you help try if the patch works with yours? Thanks!

Arthur

Thank you for your patch. I have tried it and it can list the cp apns in settings. But there is also one problem: if we first flash the device or reset the phone and then receive and process a cp message, then we open the settings for the first time and look at the apn list, we will find the cp apns are listed in the apn list twice. So I think before we added the apns in "ril.data.pending.cp.apns" into apn list, we should check if the list already have these apns.

Besides, after we store the apns in "ril.data.pending.cp.apns" into apn list, we can clear the whole pendingCpApns[serviceId] as if we change to a sim of another operator later, we can find the cp apns in 'ril.data.cp.apns' are listed on the apn list once we open the settings and look at the apns for the first time and do not need to add the apns in "ril.data.pending.cp.apns".How do you think about this? 

Thank you.

Comment 26

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8551655 [details] [diff] [review]
wappush_multi_apns.patch

Review of attachment 8551655 [details] [diff] [review]:
-----------------------------------------------------------------

I've found only some nits in the patch which generally looks good to me but I'll defer review to :jaoo who knows the code better than me.

::: apps/wappush/js/store.js
@@ +117,5 @@
>          }
>          transaction.set(data);
>  
> +        //Save the newly received apns that are not committed to the apn lists
> +        //maintained by settings app in 'ril.data.pending.cp.apns'.

nit: Please leave a space between the double slashes (//) and the following string.

@@ +121,5 @@
> +        //maintained by settings app in 'ril.data.pending.cp.apns'.
> +        var pendingApnsRequest = transaction.get('ril.data.pending.cp.apns');
> +        pendingApnsRequest.onsuccess = function() {
> +          var pendingApns = pendingApnsRequest.result['ril.data.pending.cp.apns'];
> +          console.log("JavaScript: before store"+JSON.stringify(pendingApns));    

nit: Remove this line since I assume it was used for debugging only.

@@ +142,2 @@
>            }
> +    

nit: Remove this empty line

Comment 27

[José Antonio Olivera Ortega [:jaoo]]

Sorry guys, but I'm trying to understand what issues we have here. Are we parsing the provisioning document correctly? I'd like to have a look at the provisioning document first if possible. Jinghua.Xing, could you attach it please?

Comment 28

[jinghua.xing]

Attachment: 01049_same_appid_different_provider-id.xml

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #27)
> Sorry guys, but I'm trying to understand what issues we have here. Are we
> parsing the provisioning document correctly? I'd like to have a look at the
> provisioning document first if possible. Jinghua.Xing, could you attach it
> please?

Like the document in the attachment, it will parse two default apns, But in settings aon list, only one of them can be listed.

Comment 29

[shawn ku [:sku]]

Since Arthur and partner are working on the patch, remove ni for myself.

Comment 30

[jinghua.xing]

Arthur:

I have tried to use the following code to fix the first issue I said in comment 25. Can you help to check if it is OK? Thank you.

 +        // Add pending cp apns to the apn list.
 +        if (pendingCpApns && pendingCpApns.length) {
 +          return Promise.all(pendingCpApns.map((pendingCpApn) => {
-+            return this._apnList(serviceId)
-+              .add(pendingCpApn, ApnItem.APN_CATEGORY.PRESET);
++            var matchApn = this._apnLists[serviceId]._apnItems.find(function(apnItem) {
++              return ApnUtils.isMatchedApn(apnItem.apn, pendingCpApn);
++            });
++            if (!matchApn) {
++              return this._apnList(serviceId)
++                .add(pendingCpApn, ApnItem.APN_CATEGORY.PRESET);
++            } else {
++              return null;
++            }
 +          }));
 +        }
 +      }).then(() => {

Comment 31

[jinghua.xing]

Besides I also use following codes as the second point I mentioned in comment 25
 +      }
 +      SettingsCache.getSettings(function(results) {
 +      var pendingCpApns = results[PENDING_CP_APN_KEY];
-+      if (pendingCpApns && pendingCpApns[serviceId] &&
-+        pendingCpApns[serviceId][mcc][mnc]) {
-+          pendingCpApns[serviceId][mcc][mnc] = null;
++      if (pendingCpApns && pendingCpApns[serviceId]) {
++          pendingCpApns[serviceId] = null;
 +          var obj = {};
 +          obj[PENDING_CP_APN_KEY] = pendingCpApns;
 +          var request = settings.createLock().set(obj);

Comment 32

[Arthur Chen [:arthurcc][inactive after 6/30]]

(In reply to jinghua.xing from comment #25)
> (In reply to Arthur Chen [:arthurcc] from comment #24)
> > Jinghua, could you help try if the patch works with yours? Thanks!
> 
> Arthur
> 
> Thank you for your patch. I have tried it and it can list the cp apns in
> settings. But there is also one problem: if we first flash the device or
> reset the phone and then receive and process a cp message, then we open the
> settings for the first time and look at the apn list, we will find the cp
> apns are listed in the apn list twice. So I think before we added the apns
> in "ril.data.pending.cp.apns" into apn list, we should check if the list
> already have these apns.
> 
Agree. But part of the reason is because the wap push app also not filters the duplicate apns out. I'll do the check in settings app.

> Besides, after we store the apns in "ril.data.pending.cp.apns" into apn
> list, we can clear the whole pendingCpApns[serviceId] as if we change to a
> sim of another operator later, we can find the cp apns in 'ril.data.cp.apns'
> are listed on the apn list once we open the settings and look at the apns
> for the first time and do not need to add the apns in
> "ril.data.pending.cp.apns".How do you think about this? 
> 
What if users receive cp apns with the sim card of operator A, but never enter the apn panel. And then they change to use the sim card of operator B and receive another set of cp apns. This time the users enter the apn panel. When they switch to the sim card of operator A, I think it is expected to see the cp apns of operator A when entering the panel, so we should not clear the entire pendingCpApns[serviceId]. WDYT?
> Thank you.

Comment 33

[Arthur Chen [:arthurcc][inactive after 6/30]]

PR updated: addressed the first issue in the second commit.

Comment 34

[jinghua.xing]

When user switch to the sim card of operator A, this sim card is treated as a new insert card, and in _ready() function will call this.restore(serviceId, RESTORE_MODE.ONLY_APN_ITEMS) to restore the apns stored in ril.data.cp.apns and it already contains the apns we received before we change to the sim card of operator B, so the apns also can be seen on the apn list. WDYT

Thank you.

Comment 35

[Arthur Chen [:arthurcc][inactive after 6/30]]

When restoring apns, we only add the cp apns belong to the operator of the sim card based on the mcc/mnc codes[1], so the cp apns received from operator A will not appear in the list when doing restore using the sim card of operator B.

[1]: https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/modules/apn/apn_settings_manager.js#L300

Comment 36

[jinghua.xing]

Arthur:

I mean when we first receive cp apns with the sim card of operator A, the apns are also stored in 'ril.data.cp.apns' and then we change to use the sim card of operator B and enter the apn panel, we can also clear entire pendingCpApns[serviceId]. And if we switch to the sim card of operator A again, as the codes[1], we will add the apns in 'ril.data.cp.apns' and there's no need to add the apns stored in "ril.data.pending.cp.apns".

[1]: https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/modules/apn/apn_settings_manager.js#L94

Comment 37

[Arthur Chen [:arthurcc][inactive after 6/30]]

You are right! That's why we have duplicate cp apns in the first place. One is from 'ril.data.cp.apns' and the other is from 'ril.data.pending.cp.apns'.

Comment 38

[José Antonio Olivera Ortega [:jaoo]]

Let's pause a bit a think about what to do here. There is a IOT requirement (at least one) about activating the APN being installed through OMA CP messages (see bug 1015875). With one-APN-OMA-CP-messages current code worked well and met the requirement. As there can be more than one APN in the provisioning document the WAPPUSH app message should request what APN the user would like to active. IMHO this is the right thing to do. We should request some feedback to the UX team as well. The approach I'm telling you guys about would keep the setting app as it is so no changes would be required. Thoughts?

PS. Adding Beatriz to CC as she knows about all these IOT requirements.

Comment 39

[José Antonio Olivera Ortega [:jaoo]]

Comment on attachment 8551655 [details] [diff] [review]
wappush_multi_apns.patch

Review of attachment 8551655 [details] [diff] [review]:
-----------------------------------------------------------------

Cancel current review request at me until we agree what to do here. Thanks.

Comment 40

[Gabriele Svelto [:gsvelto]]

I agree, some UX feedback is important at this point. I'm CC'ing Jenny who's in charge of both Settings and SMS/MMS UX (WAP Push falls under SMS/MMS IIRC).

Comment 41

[Arthur Chen [:arthurcc][inactive after 6/30]]

The issue is about that all received apns are not listed in the apn panel correctly, so the proposed patch aims at resolving that. Users are free to switch to the other received apn in the apn panel. 

I'm not sure under what circumstance users are receiving multiple apns in one message. Do we want to make users select one of them and drop the others?

Comment 42

[Steven Yang [:styang]]

As triage, plus it for 2.1S.

Comment 43

[Arthur Chen [:arthurcc][inactive after 6/30]]

Beatriz, could you shed light on this from the aspect of operators?

Comment 44

[Beatriz Rodríguez [:brg]]

(In reply to Arthur Chen [:arthurcc] from comment #43)
> Beatriz, could you shed light on this from the aspect of operators?
Unfortunately, we do not have a specific requirement for this scenario as it is not covered by our test plan. 
Besides, this feature was already certified at several Telefonica operations as it was since v1.3.
IMHO, this bug is a new feature request, not a real bug and should be included in backlog and reviewed by UX following specs for future releases.

Comment 45

[Arthur Chen [:arthurcc][inactive after 6/30]]

Vance, per comment 44, could you help confirm whether the feature is required for this branch?

Comment 46

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Siiaceon, per Beatriz's Comment#44, I would suggest we leave this out for v2.1s but review and check in for the main-trunk. If in the future you need this again in v.2.1s for carriers other than TEF, we can just cheery-pick it from master.

Does that make sense to you? please help to discuss with your QA team and let know the result

Thanks

Vance

Comment 47

[siiaceon]

Agree with you Vance, But our QA face to all of the customers, so the test spec level cannot be lower they said in last mail which including you. So thank you for your and mozilla good fellows' understanding. On another word, we both may need to face many customers, so it's may hard today, but can be free tomorrow,right?
However we can suggest to cut down the rule for picking TEL version.

Comment 48

[Arthur Chen [:arthurcc][inactive after 6/30]]

Jenny, for the scenario of receiving multiple apns, what we were proposing for this branch was to apply the last received apn by default, and users are allowed to change to other apns in settings app. This won't affect the existing UI. For v3, I think we can come up with a new design once we have more information on the actual usage. WDYT?

Comment 49

[Jenny Lee]

Hey Arthur, 

Is there a reason why you picked the last apn as default? 
I'm ok with selecting one apn as default, also agree that we need a more refined way of doing this for v3, user should be informed that which apn is set and that they can change it in Settings. Thanks!

Comment 50

[Arthur Chen [:arthurcc][inactive after 6/30]]

The last received apn overrides previous ones makes seems make sense, although I'm not sure about the real case.

Comment 51

[Steven Yang [:styang]]

Siiaceon, do we still need to investigate this issue?

Comment 52

[siiaceon]

Steven:
  the bug assign to sprd side jinghua, I will ask her to checkin her patch to 2.1s branch with patch mode then close this cr to reduce mozilla resource effort. So we try best to do it by ourself. If has any question we will ask. So far no problem to resolve this issue. 
Thank you so much steven.

Comment 53

[jinghua.xing]

Sorry for the delay. 

We have merged the patch in comment 20 and comment 24 in sprd side. And it can fix the issue of adding the apns from the oma cp message into the settings apnlist. Thank everyone who helped us very much.