Upsert issues

[keianrad]

Hello,

I have two forms:
- Assessment form
- Reply form

Client send inquiry by assessment form and adviser should answer by reply form to each inquiry.

The reply from is linked to the assessment form by id.

There is a status filed in the assessment form named "request status".
I need to change value of this field when I reply to assessment request.

I used upsert plugin in the reply form with below setting:
List ===> Assessment Form
PK or FK ===> Pk
Foreign / Primary Key ===> id
Row value ===> empty
Values ===> ( Key = {support_assessment_form___request_status} - Value = 1 - Default = empty - Eval= No)

but it didn't work!!!!

 

[cheesegrits]

Once again, I can't get in to your site because of the htaccess. I suggest while you are developing this Fabrik app and are going to be needing support, you set it to the same as the password for our account. Or specify the htaccess password in the notes in your My Sites.

-- hugh

 

[keianrad]

I set the same password for that one also.

Thank you for helping.

 

[keianrad]

 

[cheesegrits]

OK, the tooltips and wiki aren't very clear, but when in PK mode, in "Row Value" you have to specify the placeholder for the FK element on your submitting form which points to the PK on the table you are upserting. In your case I think that would be

{support_reply___reply_as_id}

So when the plugin runs, it takes that value (which should be the 'id' of the assessment form this is a reply to), and uses that to lookup the row in the table you are upserting, against the element you selected as the "Foreign / Primary Key".

-- hugh

 

[keianrad]

I did but it just creates a new record.

I changed name of "support_reply___reply_as_id" to "support_reply___assessment_id" for better understanding.

 

[cheesegrits]

But now you've changed it to FK mode?

-- hugh

 

[keianrad]

I tried both FK/PK but it doesn't work.

 

[cheesegrits]

I was in the middle of working on the site when it started doing "this site can't be reached, taking too long to respond".

This has happened several times while I've been on the site before, it seems there's either an unreliable network hop between me and the server, or the site itself gets hung up occasionally.

I'll try again later.

-- hugh

 

[keianrad]

Oh, Maybe it is related to website firewall. Please send me your IP address then I will add it to white IP list.

 

[cheesegrits]

75.76.125.36

-- hugh

 

[keianrad]

done.

 

[cheesegrits]

Nope, still no luck.

It seems to be a routing issue between me and your site. If I traceroute to your server form here, my packets stop in Dallas at a Levels.net router. And I can't even ping your site. But if I go somewhere like "downforeveryoneorjustme.com" and check, it shows your site is up.

So yup. Some kind of BGP routing issue on the backbone between my provider and yours.

-- hugh

 

[cheesegrits]

I still can't get at your site.

Here's what the traceroute looks like from here:

Tracing route to support.xxxxxxxxxx.com [x.x.x.x]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    11 ms    12 ms    13 ms  user-24-96-68-161.knology.net [24.96.68.161]
  4    10 ms    10 ms    10 ms  user-24-96-153-133.knology.net [24.96.153.133]
  5    28 ms    28 ms    27 ms  user-69-73-5-25.knology.net [69.73.5.25]
  6    31 ms    28 ms    28 ms  dynamic-75-76-35-11.knology.net [75.76.35.11]
  7    30 ms    29 ms    29 ms  static-76-73-191-225.knology.net [76.73.191.225]

  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10    82 ms   116 ms    95 ms  COLO4-DALLA.ear1.Dallas1.Level3.net [8.9.232.74]

 11    58 ms   171 ms   198 ms  72.249.137.132
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *     ^C

... and pinging ...

C:\Users\Hugh>ping support.studyabroadagency.com

Pinging support.xxxxxxxxxxx.com [x.x.x.x] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for x.x.x.x:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

-- hugh

 

[keianrad]

I checked it with my server. and It seems it is ok:

"I did a reverse tracert and it shows this:

traceroute to 98.226.60.56 (98.226.60.56), 30 hops max, 60 byte packets
1 72-249-30-1.static.directrouter.com (72.249.30.1) 0.335 ms 0.364 ms 0.385 ms
2 72.249.137.131 (72.249.137.131) 0.258 ms 0.236 ms 0.212 ms
3 xe-0-4-0-12.r01.dllstx04.us.bb.gin.ntt.net (129.250.202.253) 2.792 ms 2.880 ms 2.909 ms
4 ae-9.r07.dllstx09.us.bb.gin.ntt.net (129.250.2.208) 1.278 ms 1.202 ms 1.275 ms
5 ae-0.comcast.dllstx09.us.bb.gin.ntt.net (129.250.66.30) 1.496 ms 1.191 ms 1.500 ms
6 be-12495-cr02.dallas.tx.ibone.comcast.net (68.86.85.193) 1.958 ms 2.925 ms 3.402 ms
7 be-11724-cr02.denver.co.ibone.comcast.net (68.86.84.229) 16.822 ms 16.745 ms 16.820 ms
8 be-10517-cr02.350ecermak.il.ibone.comcast.net (68.86.85.169) 31.080 ms 31.074 ms 31.066 ms
9 be-7922-ar01.area4.il.chicago.comcast.net (68.86.91.166) 30.345 ms 30.370 ms 30.364 ms
10 be-124-rur02.wchicago.il.chicago.comcast.net (162.151.45.110) 32.871 ms 32.917 ms 32.867 ms
11 ge-14-0-cdn01.mortongrove.il.chicago.comcast.net (68.86.117.194) 32.340 ms 32.407 ms 32.499 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *

This ip is not blocked on our server. Thank you."

 

[cheesegrits]

Right, but you aren't going through Level3 in Chicago, your traffic takes an entirely different route. You need to talk to your host, show them that traceroute from here.

I still can't get at your site, which means that anyone else routing through Level3 will have the same problem.

-- hugh

 

[cheesegrits]

I just had a similar issue with someone else, who hosts with Rochen, and it turns out my IP was blocked, but at a level that didn't show in their control panel, and had to be unblocked by Rochen.

Can you check with your host that my IP hasn't gotten blocked at some level you don't have access to?

75.76.125.36

-- hugh

 

[cheesegrits]

w00t! I can finally get back into your site.

Do I still need to look at this?

-- hugh

 

[cheesegrits]

Ah HAH!

OK, I'd completely forgotten about this wrinkle.

During the upsert, the form data isn't really in "placeholder friendly" format. When submitted, things like radio buttons, checkboxes etc are arrays, not simple string values. They don't get converted to placeholder format until after things like the upsert plugin runs.

So to get the radio selection, rather than using a placeholder, we have to set it to "eval", and grab the result directly from the submitted data ...

return FArrayHelper::getValue($this->data['support_reply___reply_status_raw'], 0, '');

... in order to grab the actual selection from the submitted array. I'm using FArrayHelper::getValue() there, rather than just doing ...

return $this->data['support_reply___reply_status_raw'][0];

... to avoid getting a PHP warning if there is no selection and the array is empty.

I'll update the wiki to mention this.

Your upsert should be working now.

-- hugh

 

[keianrad]

Ah HAH!

OK, I'd completely forgotten about this wrinkle.

During the upsert, the form data isn't really in "placeholder friendly" format. When submitted, things like radio buttons, checkboxes etc are arrays, not simple string values. They don't get converted to placeholder format until after things like the upsert plugin runs.

So to get the radio selection, rather than using a placeholder, we have to set it to "eval", and grab the result directly from the submitted data ...

return FArrayHelper::getValue($this->data['support_reply___reply_status_raw'], 0, '');

... in order to grab the actual selection from the submitted array. I'm using FArrayHelper::getValue() there, rather than just doing ...

return $this->data['support_reply___reply_status_raw'][0];

... to avoid getting a PHP warning if there is no selection and the array is empty.

I'll update the wiki to mention this.

Your upsert should be working now.

-- hugh

Should I add these codes in the value of upsert plugin and set eval to yes?

If yes, I did but it doesn't work.