Transfer to ingroup API locks Ingroup choice

[alo]

Not sure if this is a bug, but I updated to the latest SVN and it still happens:

when initiating a transfer using the Agent API like: function=transfer_conference&value=DIAL_WITH_CUSTOMER&ingroup_choices=Closer1&consultative=YES

The call transfers to the Ingroup Closer1 as expected. but if the agent hangs that call up. (either using the API or the agent pressing Hang up xfer line) and then tries to transfer to a different ingroup, it will keep transferring to the one that was selected in the API. Its basically locked to the ingroup selected in the API call.

As a note, if you send a new API call with a different Ingroup, it will transfer to that new ingroup, then anytime the agent tries to manually transfer to a different ingroup it will go to the new one from the API.

Has anyone seen this "feature" and is there a way to not have it get locked to whatever ingroup is sent in the API?

Thanks!

[carpenox]

I would submit this to the mantis tracker up top.

[williamconley]

Not sure if this is a bug, but I updated to the latest SVN and it still happens:

when initiating a transfer using the Agent API like: function=transfer_conference&value=DIAL_WITH_CUSTOMER&ingroup_choices=Closer1&consultative=YES

The call transfers to the Ingroup Closer1 as expected. but if the agent hangs that call up. (either using the API or the agent pressing Hang up xfer line) and then tries to transfer to a different ingroup, it will keep transferring to the one that was selected in the API. Its basically locked to the ingroup selected in the API call.

As a note, if you send a new API call with a different Ingroup, it will transfer to that new ingroup, then anytime the agent tries to manually transfer to a different ingroup it will go to the new one from the API.

Has anyone seen this "feature" and is there a way to not have it get locked to whatever ingroup is sent in the API?

Thanks!

I have bumped into this a few times, a long time ago. Pretty sure it was resolved in an upgrade. Equally sure the client never noticed it and we never got a ticket for it (read that as "no way to check history and find out when/version/etc").

But I digress: You have not provided your Installer, your Vicidial version with build or even your asterisk full version.

I would also suggest you provide whether you've upgraded your system after the installation. Sometimes configuration options/settings in some of the settings files have to be upgraded for versioning to mesh properly with code and commands, thus an upgrade can cause oddities like this.

I would also suggest you trace the problem in the agent java console and see if the correct command is present there or if it has somehow been locked in or even tosses an error when trying to change (which would explain how it can't change, of course, once set: a javascript crash during change attempts would block the change, but no crash during "submit" would continue to allow submission).