Hi, i notice that "company contacts" has been made unmanageable, see [this thread](https://www.thirdlane.com/forum/cannot-addedit-company-contacts)
We use the company contacts to generate an XML for a remote directory for handsets, and this functionality being removed is quite a problem - especially since we are now editing the SQL by hand and apparently this is causing issues with connect.
so i would like to propose these solutions:
1. since an un-managed "Company Contacts" is just "firstname lastname ext" from user extensions, then remove the interconnection with "Connect" and re-enable management of company contacts.
2. alternatively, clone company contacts into "External Contacts" (including selectable permissions etc same as company contacts) but this doesnt interact with connect. That allows us to "give" end users the ability to edit a remote directory. You could even include it as CID lookup for incoming calls
3. Have "Connect" view a subset of the "company contacts" (eg select * from directory where ext is not null) and manage only the "internal" directory, leaving us free to have end users manage any without an ext as "external" directory.
i think 3 will have the quickest resolution, and 2 would provide the best of both worlds.
thanks
Hi Alex,
Hi Alex,
How about keeping the "company contacts" as you want it, but cloning the table format, the permissions for management etc into a new "external directory", then clone the data from the company directory.
that allows you to keep the company directory how you use it, and you know all the data in the "external directory" is just for ...idunno possible CID matching on inbound much like how freepbx allows you to lookup from "asterisk phonebook".
that gives everyone else a new "feature" of CID matching, and those few like us who were using it to generate remote directories in XML form for Cisco and Yealink phones still have a "end user manageable with permissions" sql table that we can look it up from!
how does that sound?
Contact management will be
Contact management will be available in the next release. The way it will work is that the extension in contact records will not be editable, and contacts that have the extension filled in will be considered "local", and therefore "not deletable" via directory.
The problem is not only with Connect. Unfortunately, there is no reliable way to know which contacts are the "clones" of User Extensions (and should not be managed via directory), and which contacts are external (as these could have same extensions as user extensions). We could fix this problem by associating directory entries with newly created User Extensions going forward, but it is not clear what to do for the existing contacts - just matching on extension is not enough. We could patch the existing system by matching on extension and name, and if all fields match, then it is most likely that the contact is a "User Extension" and should be flagged as "not be managed via directory" - but even that is not perfect.