Custom User Fields in 16.0.40.7

Hi,
Is there a way to add custom fields (via GUI) to a user group (or users). I run 16.0.40.7

I don’t seem to find anything in the documentation, doesn’t exist natively? If not, is there any optional module that would allow to add them via GUI?

Custom fields for what exactly?

Specifically, I’m toying with a GUI based solution to indicate group preferred outgoing CIDs. I would create for example default_cid, default_cid_ca (Canada), default_cid_LOCATION for specific area(s) and have custom destinations refer to those settings rather than the custom destination itself. This is because it would be a lot more user friendly and intuitive for a non-technical user to be able to access and change them from there.

If they can’t be created from GUI, perhaps I’ll need to go the module route or simply give up and work with different custom destinations direclty.

Why wouldn’t you just make different outbound routes for this and use something like *31 or another star code to use that route? Then you can just make the outbound CID what you want based on the route used.

That is not feasible for our user case as all our users are on softphones and all use click to call extensively. Dialing a prefix per route will either break click to call or require us to mess with the CRM number record itself, both of which we don’t favor.

So, we gave up on this method. Maybe we’ll dedicate more resources to a module down the road.

I think allowing custom fields for groups and users would be a great feature and significantly improve interoperability opportunity between systems, lowering barriers of entry. Most systems these days are API Saas based and a gazillion of them can be integrated via anything from custom work to Zapier etc.

Not to mention our original user case.

Well you really haven’t provided a lot of details out of “I want custom fields for CIDs” but not a mention of how those custom fields would actually be used in a scenario. How would your app or whatever you are doing know which CID to pick when it makes a call?

As a premise: I can’t test it without manually messing with the database to create the field. Will not.

The untested theory is that it should be possible to indicate the CID in the oubound route as a macro and use the group() function to retrieve the information. Then it could be used alone or in conjunction with custom destinations or extensions_custom.conf to determine final CID.

This really doesn’t answer the question. Are you trying to base the Outbound CID from the destination number being called? How will the Outbound CID be selected from these fields, if they existed?

Macro() is dead. You’ll need to use Gosub. GROUP doesn’t retrieve information from a source, you have to set the GROUP category and what is in it. If I was to dial 1313666XXXX what is the logic to determine this is US not Canada? How is it determined that field default_cid_LOCATION needs to be used here instead of default_cid or default_cid_ca?

Are you saying you’re going to create a misc destination that matches 1313666XXXX and apply what you need there before sending it out an outbound route?

There is one field associated with each extension that is usually free to use for whatever you want, the accountcode field. In your shoes, with a need to manage dynamic outbound cid with a GUI, I would use that field to indicate membership in a specific group and then offload all the rest of the logic to an API to determine the outbound CID. Something like this:

Yes, I see that is confusing. Also, Tom, just to clarify, I did not intend to spark controversy saying “we gave up on this method”. It was just a consequence of the custom field not being a thing.

Anyway, back to the user case. Let’s try to go back to the absolute basic. Say that I do have that custom field, and say that the user group name matches the oubound route name. Would this work to retrieve the CID and use it when placed in the outbound route CID setting?

GROUP(${OUTBOUNDROUTE}|default_US_CID)

Hi Lorne,
Yes, you are right to point at accountcode. I did look into it following your suggestion. For some reasons I cannot find the field in user settings (I run v16) but I will experiment with it.

However, I have doubts about it’s usage for more complicated solutions (like the one you helped me at here). Is the following understanding correct?

  • Can I set accountcode under group settings - not via GUI but bulk import?
  • If I have multiple CIDs per user group that will then be handled via custom destinations (or extension_custom.conf), I would probably have to cram them on a field and parse them but at that point I better just work it on custom conf

For additional clarity, I was trying to find a more user friendly way to set CIDs without me (i.e. only me) having to work on custom destinations every time a number gets added or changed. Any admin user could easily change a value in user group, less so when tinkering with configuration files.

I don’t think you have an understanding on how GROUP works. First you need to create the group like so:

exten => s,n,Set(GROUP(${OUTBOUNDROUTE}|default_US_CID)=SOMETHING)

If that group category doesn’t exist, it creates it and adds SOMETHING to it. If you just call on the group and nothing has been added to it, then it will just be empty.

exten => s,n,Noop(${GROUP(${OUTBOUNDROUTE}|default_US_CID)}) ;if nothing in it, empty

What group settings are you referring to?

You are totally right :sweat_smile:

This is what I did not understood:

  • The CID setting in outbound route can only be static. If logic needs to be implemented it has to be done in other ways like custom destinations or extensions_custom.conf

  • The group() function has nothing to do with user groups and cannot be used to retrieve user group information as part of a dynamic route. Hence, I now fully understand why Lorne kept correctly pointing me to accountcode, as there is no other custom value that can really be used in this context (let alone custom fields).

Thanks for your help. I’ll go back to work on my configuration.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.