David ROBERT

Jeffrey, you're right to point out that the extension price is not that high. We can afford to pay that fee once more. I think that some clarification about (no)update policy is in order so that it's cristal clear for all wanting to buy such extensions. Waiting to hear from Combodo on this. As a sidenote, even if there is no support included with the extension, a 60 to 90 days free upgrade policy would be a nice thing, avoiding the annoying situation where one buys a version only to see an update...

Jeffrey, you're right to point out that the extension price is not that high. Wa can afford to pay that fee once more. I think that some clarification about (no)update policy is in order so that it's cristal clear for all wanting to buy such extensions. Waiting to hear from Combodo on this. As a sidenote, even if there is no support included with the extension, a 60 to 90 days free upgrade policy would be a nice thing, avoiding the annoying situation where one buys a version only to see an update...

Does anyone know how to upgrade a paying extension that was acquired from the iTop Hub ? We use iTop Communitiy Edition. In March we acquired a paying extension (Auto dispatch ticket to a team 1.0.6) for 199€. iTop hub notified us that there was a new realease (v1.0.8) available but the only way I see to get it is to buy it anew for 199€ just to update it. Nowhere on the hub can I find any reference to the licensing used for such paid extensions when bought outside of a support contract and I do...

Uh... what about company of a sufficient size to have several instances of persons with the same name working in different departments? (2 such cases of perfect homonyms here...). Duplicate Names is not an issue. Duplicate email or employee number is. Such a "Confirlm" dialog would be useful, provided discriminating information as email and/or employee number are displayed in dialog so as to make sure it's a not duplicate being created.

Backtracking the error message I ended reading in the code that public function IsFqdnUnique() actually "takes into account the global parameters that defines if duplicate FQDNs are authorized or not" Duh... Parameter found, IPv4 addresses sync properly now. Another RTFM issue with chair-keyboard interface. Sorry...

VMware vSphere data collector / IPv4 Error if VM has multiple IP addresses

Data Collector for vSphere & TeemIP : filter out APIPA IPv4 addresses

Data collector for vSphere 1.0.11 + TeemIP: Synchro Data Source naming We have been using this collector in a multiple vCenter environments for years now using the trick described in collector doc (separate instances using some common files using links). ​ But lately we have started using the TeemIP extension. And we ran into an issue with Data Source naming: ​ I noticed that all synchronizations were properly created with their specific prefix (one per vCenter) except 2 that are still created with default **vsphere** prefix: *lnkIPInterfaceToIPAddress* and *LogicalInterface*. ​ So we end up with 9 Data Source per vCenters (Brand, Farm, Hypervisor, IPv4Address, Model, OSFamily, OSVersion, Server and VirtualMachine) and 2 lone Data Source with vSphere prefix: **vSphere **:*lnkIPInterfaceToIPAddress* **vSphere **:*LogicalInterface*. ​ I had a look into the JSON file of those two collectors and found the issue. Instead of the usual "name": "$prefix$:item" name definition we have in all other collector's JSON files, those 2 use a name definition not using the $prefix$ variable : "name": "vSphere:lnkIPInterfaceToIPAddress" "name": "vSphere:LogicalInterface" ​ For now, I just corrected the JSON files and altered the source file we keep in our DML for further env deployment. But I'd like to see this corrected in the future. Data collector for vSphere 1.0.11 + TeemIP: Synchro Data Source naming