Requested for has different value then Opened by

[Dan R3]

I have a couple of situations occurring and can't figure out why they are happening. While the situations are very similar, they don't seem to overlap and don't seem to be related (could be coincidence, could be something I'm missing)

Issue #1 - A user fills out a form on the Service Portal. This particular form has no field to alter the "Requested by" field, so OOB, the person who opens the ticket should populate in the "Requested by" field. (or so I would think)

       ex: When user A opens the ticket, the name of User A remains in the "Opened by" field, but User B is put in the "Requested by" field (User B is a user completely unrelated to User A).

This issue can be duplicated in all instances, dev, test, and prod.

Issue #2 - Essentially the same problem as #1 but with a different user and a different cat item, except it's happening only in prod and can only be duplicated in Prod. Again the user in the Requested by field is completely unrelated to the person opening the ticket.

What's frustrating here is that when I try to duplicate the issue with a different user, I can't get the issue to duplicate. Furthermore, if I open a different catalog item with the same user, it seems to be fine, no issues. To me, that would indicate it's isolated to the specific user and the specific catalog item, but for the life of me, I can't figure out why this is happening.

I don't see any business rules altering the field. The only change we made, was setting the value of glide.sc.sp.twostep to false. When this sys property is set to false, two step checkout is disabled in the service portal.

Is this property creating a glitch that is causing this problem?

Any idea on where to investigate or why this is occurring?

I appreciate any response/advice that anyone can give.

Thanks in advance.

Regards,

Dan R

[Allen Andreas · Accepted solution]

Well, glad you got it figured out. Hopefully I helped somewhat and did call-out that system property previously.

Take care!

[Allen Andreas]

😉

[Paul Bloem]

Hello,

I know a solution has been accepted here, but I just wanted to add that I had the same issue and tracked down the data issue causing the problem. 

On the sc_cart table, there was an record with the following values:

• User: <User A>
• Requested For: <User B>

I deleted the record, and everything worked as normal again.

I don't know how the record was created and don't care to spend more time investigating, but in case someone else runs across this, it's a pretty easy fix and hopefully this saves them 4 hours of digging like I did! 🙂

Best,
Paul

[Husam]

Hello,

I just had the same issue, and after reading through this thread and looking through my instances, I found where this issue is coming from and how to replicate it.

Essentially, when two-step checkout is enabled, user's can choose to request an item for someone else. However, when doing so, the requested_for field on the default sc_cart record for that user is updated to whoever they selected when checking out. Then, if two-step checkout is disabled, every time the user orders, the requests will be created for who they selected last while two-step checkout was enabled.

Steps to replicate issue:

1. Enable two-step checkout.
2. Impersonate <User A>.
3. Order an item, and set the "Requested for" field to <User B>.
4. 1. Note that the record in the sc_cart table with Name: "DEFAULT" and User: <User A> has the "Requested for" field set to <User B>
5. Impersonate an admin and Disable two-step checkout.
6. Re-impersonate <User A>
7. Order an item
8. 1. Note that the sc_request has "Requested for" set to <User B>

The reason re-enabling two-step checkout would solve the issue is that when <User A> goes to order an item again, the "Requested for" field auto-populates with the currently logged in user (User A), and the sc_cart record for that user is updated to have "Requested for" set to <User A>.

Hope this helps,

Husam