Sneak preview! Update 6 has reached Release Candidate (RC) status, as 3CX Developers move to ‘Code-freeze’. With all QA test checks on Linux and Windows completed with thousands of customers worldwide, we’re now up and fully running in 3CX production. We’re confident it’s ready for you too! In a nutshell, this very important RC brings you...
Ok ok,
I'm sorry, I'm sorry, it's my fault.
In my POST data, I can no longer send to 3CX ...
JSON:
"media_url": "",
"media_file_name": "",
"The JSON Keys" cannot contain empty values !
My wife keeps telling me to follow the assembly guide when buying new furniture !
Must believe that his advice also applies to 3CX ... "Guillaume, follow the instructions of 3CX and you'll be fine"
that said, for those interested, the Provider Template must now contain;
HasWebhook [ Yes or No ] , it leaves room for imagination. Who knows, it may leak as a clue that 3CX is already at the stage of providing RCS (Rich Communication Services) support.
Or, I'm completely wrong, maybe it just means.. "Enable WebHook" .. lol
Self-mockery (To make fun of oneself) :
I make myself scenarios, as if I could "discover" the secrets (new features) of future 3CX releases, as if 3CX was "hiding clues" to satisfy the curious like me lol What I don't know is that maybe the 3CX devs are looking at my post and suggesting to their leader....
"We should add/hide a fake phone template in the next release.
Make it look like 3CX is going to will launch a Desktop phone".
!!!! That would be terrible, as joke lol !
Ok ok,
I'm sorry, I'm sorry, it's my fault.
In my POST data, I can no longer send to 3CX ...
JSON:
"media_url": "",
"media_file_name": "",
"The JSON Keys" cannot contain empty values !
My wife keeps telling me to follow the assembly guide when buying new furniture !
Must believe that his advice also applies to 3CX ... "Guillaume, follow the instructions of 3CX and you'll be fine"
that said, for those interested, the Provider Template must now contain;
HasWebhook [ Yes or No ] , it leaves room for imagination. Who knows, it may leak as a clue that 3CX is already at the stage of providing RCS (Rich Communication Services) support.
Or, I'm completely wrong, maybe it just means.. "Enable WebHook" .. lol
Self-mockery (To make fun of oneself) :
I make myself scenarios, as if I could "discover" the secrets (new features) of future 3CX releases, as if 3CX was "hiding clues" to satisfy the curious like me lol What I don't know is that maybe the 3CX devs are looking at my post and suggesting to their leader....
"We should add/hide a fake phone template in the next release.
Make it look like 3CX is going to will launch a Desktop phone".
!!!! That would be terrible, as joke lol !
Check out the update files in the logs... messaging provider is a new one and contains currently Facebook and WhatsApp. My guess is RCS might come there or Telegram.
Finally getting some time to try update 6 RC and the new groups.
To check my understanding, in order to ensure the group timezone and holidays are applied to a call on an existing trunk (from an upgrade) with many inbound rules for DIDs:
From the management console (MC) > inbound rule > select the destination to be "send to call group" and pick the group representing your branch/dept.
Move to the web client/desktop app and go to admin > groups and 'call routing' link that takes you over to the office hours menu and from there route the call to your queue/ring groups?
The timezone / office hours applied to the user come from the 'main group membership' on the user record in the web client (can't see that field anywhere in the MC).
A few queries,
Will you add multi-user bulk editing functionality to the webclient > admin > users section in the future? Or if multi-editing is to remain in the MC as an advanced feature can you please expose the 'main group membership' field to the extensions section?
Looks like the main group membership drop down list is ordered by when the groups were added to the user, so it is a different order for different users. Means you have to click through each user one at a time to apply the correct main group?
The CSV export from the web client only includes first/last name, email, mobile; no group membership. Likewise I couldn't see main group field in the MC extensions export CSV. So appears to be no bulk way to assign main groups membership?
If using MC inbound rules to send calls to groups on existing DIDs, there are in office hours and out of office hours routes on the inbound rule. Is it basically a 1:1 mapping to the in/out office routing in the webclient group routing? eg: You send both the inbound rule in/out office hours to the same group. But I assume this means you could override (accidentally or on purpose) the out of office hours routing at the rule level to somewhere other than the group.
If you add a new supported trunk from the webclient > admin > voice and chat section and 'limit it to a group' rather than 'system wide', I can't find a way to change that choice later other than deleting and re-adding the trunk to be system wide? Is that the case at the moment?
Cheers. Looking forward to handling multiple timezones / holidays in one system.
@MarkNAS - Thanks for summary - see feedback below
From the management console (MC) > inbound rule > select the destination to be "send to call group" and pick the group representing your branch/dept.
Well, you can also just assign the DID directly to the group from the webclient
Move to the web client/desktop app and go to admin > groups and 'call routing' link that takes you over to the office hours menu and from there route the call to your queue/ring groups?
Thats where you configure groups for times yes
The timezone / office hours applied to the user come from the 'main group membership' on the user record in the web client (can't see that field anywhere in the MC).
Yes
If using MC inbound rules to send calls to groups on existing DIDs, there are in office hours and out of office hours routes on the inbound rule. Is it basically a 1:1 mapping to the in/out office routing in the webclient group routing? eg: You send both the inbound rule in/out office hours to the same group. But I assume this means you could override (accidentally or on purpose) the out of office hours routing at the rule level to somewhere other than the group
You have to choose one or the other. Either send to group or keep old system wide hours
If you add a new supported trunk from the webclient > admin > voice and chat section and 'limit it to a group' rather than 'system wide', I can't find a way to change that choice later other than deleting and re-adding the trunk to be system wide? Is that the case at the moment?