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]

Hi,

Can you please elaborate...unfortunately, you're leaving out a crucial piece and not mentioning where user B is coming from (in your first example)...obviously the system isn't just up and picking a random user, so somewhere on the form or otherwise, user B is coming in to play. How is that done?

And this is solely for catalog items?

OOB there is logic in place to put the requested for on the actual request the same as who is opening it....but on the request item...it could be completely different (could be the requested for that was supplied in the cat_item).

Then in the service portal, if you're using that, there's a two-step validation that occurs asking you to confirm who it's for and you could change the name there to someone else...So in essence there could be a requested_for on the RITM....a requested_for on the request....and an opened_by....so 3 people could somehow get involved in all this.

Explain a bit more if you can where user B is even coming from...thanks!

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Dan R3]

Hey Allen,

Thanks for taking a stab at this one.

Unfortunately the thing is, there is NO relation between User A and User B in either scenario. They are in different departments, different titles, no delegation set up in anyway.  I guess that's really where I'm stuck. I've tried to look through Business Rules that effect both the sc_request and sc_req_item tables, but no luck on pinpointing the fault. I do see the logic you're referring to that adds the opened_by to the requested_for field for sc_request, but it looks standard OOB.

To answer your question: in both scenarios I can only duplicate this issue on a single catalog item with a single user (different items in each scenario, and different users (meaning User A in scenario 1 is not the same as User A in scenario 2)). I agree with you that it would be extremely odd (and most likely a serious bug) if the system was picking up a random user, however I just don't know where to look at this point to figure it out.

Important forgotten detail:

Furthermore, we've disabled the 2-step checkout process. I fear this is where the issue lies... however the only change that was made for that was setting the sys property :

glide.sc.sp.twostep = false

I actually just tried a test in DEV for scenario #2 (since that was the only scenario that I could duplicate the issue in multiple instances), and when I changed the system property back to true, the issue disappeared.

Could this be an undiscovered bug?  I appreciate you taking the time to discuss/address Allen. Thanks for your comments.

[Allen Andreas]

In scenario 1...is it always the same user B that gets brought in to the scenario?

If you don't mind and have time, could you sort of screenshot your process...like showing the catalog item form, how it's filled out, what the checkout page/order status page says, and then in the back-end and list of items requested, the ordered_by, requested_by and/or requested_for fields? 

Still not understanding the scenarios and if you're meaning it's random users....or the same user each time for the same person you're doing the scenario as.

[Dan R3]

So yesterday I was able to duplicate the issue non-stop, however just now, i was going through the process to duplicate the issue and take screenshots for you, and somehow after toggling the value of the sys property glide.sc.sp.twostep from false, to true, and back to false, the issue has now disappeared. I've opened 3 tickets now and it seems to have corrected itself.

To simply address the question you posed in the last comment, User B was always the same, unrelated user. I think for now I'm going to call this resolved, but I'm going to open a Hi ticket to see if it's even possible to get to the root cause.

Happy to discuss more if you'd like to better understand what's going on.

Thanks again for your help and time.