This will go nowhere if I try to raise a support case so I"m asking here in hopes one of the dev team spot this post and contribute.
About a month or so ago, we noticed that the behaviour of caller ID had "changed" in that in some cases where calling on behalf of queue, if no queue Calling Number was set, the users DID was presented instead. Previously this used to fall back to the next item on the prioritisation list set on the trunk. In other cases, that prioritisation worked as we expected.
In some of my own testing, it appears that at some point within the last month or so, the UI for the queue management changed. Previously this used to present a list of country codes. Now it has a single text field with a reminder to include the country code. Around the same time as this UI change happened, the calling number presented in different ways:
A newly created queue with no calling number set had this field NULL
If the calling number that was previously set on a queue was deleted, instead of that presenting as NULL in the UI would show as "undefined" or "+undefined". In this scenario a query of the queue via API would also show as undefined rather than NULL.
What we discovered through a number of tests was that depending on whether your queue's calling number was set as #1 or #2, the outbound calling number behaviour would differ.
Now it seems within the last week or so this behaviour has changed yet again and the "undefined" text no longer presents.
I am struggling without much luck trying to convince Genesys Care that was was indeed the case as by the time I convinced the support rep to try to replicate this, the behaviour had changed.
If there's a Genesys dev spotting this post could I please ask you to check into this for me and advise? It definitely seems to me that something in the underlying API changed and then changed again over the space of about 4-6 weeks in either how the API updates or reads the queue configuration.
The GET PUT against /api/v2/routing/queues/ (when being called from the UI in the case of PUT). For about a month or so, the PUT was adding "undefined" or "+undefined" as the value for the callingPartyNumber if you went into the UI and cleared out an existing ANI. When querying the queue via the GET we'd see that undefined value.
Now though - as of about a week or so ago, when you erase an existing ANI in the UI, it removes that entire property from the queue object configuration.
However, what I have also noticed is if you put in a number but without the leading + it adds that for you fine. But if you type in anything alphabetical it reverts back to putting "undefined" in there. If I put just 0 in the number, the API updates that as +0. While the input field has a hint saying remember the country code, there's nothing realy warning you that it will actually accept anything in there.
This has a flow on effect as it alters the behaviour of calling on behalf of queue.
Sorry, I missed the reply notification for this post.
That sounds like a bugfix in the UI. Seeing the literal string "undefined" happens in JavaScript when you try to concatenate an undefined variable with a string in certain circumstances.
I'd report this, and any other UI behavioral aberrations, to Care as a bug. Sounds like some cases got fixed, but not all.
My main question here though TIm is are you able to tell me if something did actually change on your side? My experience with bringing this type of thing to Care has not been a good one and they struggle at times with just getting something past onto devops etc based on "our word" and we get mired down in process
This whole thing has a bit of a flow-on effect and so there's a real risk the care ticket becomes a mess as they also struggle with multiple "issues" all related to one particular item, eg if this queue change impacts outbound caller ID presentation, they ask for a separate case on the caller ID presentation and one on the queue config but they are both tightly related.
How would you suggest this be worded so as to expedite things through the care "checkpoint"?
There are hundreds of changes in the platform every single day. What you're reporting sounds like a bugfix, which are typically not announced. Breaking changes and new features are what you'll find in the release notes and dev forum announcements.
The real question is what are you hoping to accomplish with this investigation? Maybe after some back and forth with Care you'll get an answer that yes, indeed it was changed. Or maybe you won't get a solid answer. Either way, then what? The behavior is what it is today, and a bugfix won't be rolled back because you preferred the bugged behavior. You'll have background knowledge of the situation, but nothing will change.
I don't mean to convey that your interest doesn't matter, but is expending the effort to get this answer from Care worth it to you? If it is, go ahead and open a case with Care. My advice is to be as clear and concise as possible and provide evidence of the previous behavior. Opening multiple cases so each one can hyperfocus on a single question is probably better than asking multiple questions in one case.
