What should have its own class?

• IP Phone (already present)
• IP Camera

We have several other controllers (doors, time registration, technical...). Currently documenting them as "Servers". It's only useful to have a separate class if there are lots of those type of CIs. Another option is to extend the Server class with a couple of options.

Another option:

• IP Device (abstract class)(similar to network device, with optional management ip)
  -- IP Phone (optional internal, external number)
  -- IP Camera (no additional fields)
  -- IP Generic Device (no additional fields)

TeemIP adds "IP Address" to IP Phone. Unwanted behavior towards our extension.

Issue does not occur with the new classes IPDeviceGeneric, IPDevice, IPCamera.
But there, the wanted behavior might be to have a similar dropdown list of IP addresses when using the TeemIP module.

There are a few options.

• maintain a separate version for vanilla iTop
• maintain a separate version for iTop + TeemIP Module
• maintain both as separate versions
• maintain a version for vanilla iTop and offer additional redefinitions for TeemIP Module

TeemIP overloads some stuff, so this might get tricky at some point!

Type: issue

Version info:

iTop version 2.7.0-beta2-5120 built on 2020-01-29 12:01:24
Data model: 2.7.0-beta2
MySQL: 10.1.41-MariaDB-0+deb9u1
PHP: 7.2.27-1+0

• Extension (if applicable):
  jb-ssid

Description:
Hi,
I try your data model jb-ssid install on our instance of iTop and I see this:

The following modules have unmet dependencies: Datamodel: SSID - wireless networks documentation (id: jb-ssid/2.6.200123) depends on itop-request-mgmt-itil/2.6.0

I know that our version is 2.7, but I think that problem is about using itop-request-mgmt (simple request managmet).
Can you try fix it for using both: simple and ITIL?

Thanks Jaroslav

Type: request

Version info:

• iTop: 2.7
• PHP: 7.2
• MySQL: 5.7
• Extension (if applicable): certificates

Description:
Hierarchical view for certificates

Type: request

Version info:

• iTop: 2.7
• PHP: 7.2
• MySQL: 5.7
• Extension (if applicable): Mail to Ticket Automation

Description:
Make it accept regex (too) instead of just email addresses.
This way it could accept more specific aliases or domains or ...

Didn't see any formal way to get in touch with you. Did I miss something?

Currently also still a script based on what can be found in iTop's discussion forums.

A new class should be created, which should allow:

• server
• port
• secured (separate field or part of port?)
• field to define the filter (currently filtering users with phone numbers; and another script which takes users from one particular OU within the same Active Directory to link them with a different organization)
• set default organization
• choose fields to sync (one way)
• sync frequency

Type: feature request / enhancement

Versions:

• extension: Mail to Ticket Automation
• iTop: 2.4.1
• PHP: 7.1
• MySQL: 5.7

Description:
a user requested help for tickets which were not processed. This happened because their client uses IR-01234567 as a format for their references. This obviously overlaps with iTop's default R-0123456 ticket referencing.

The idea is to implement a 'remove_patterns' field (multiline: one pattern per line). This would either be completely removed or bypassed when processing the mail title to check if there's a reference.

This would not help if another user used iTop with exactly the same settings though

The GetRelatedTicket method should become something like this

if ($oTicket === null)
{
    // No associated ticket found by parsing the headers, check
    // if the subject does not match a specific pattern
    $sPattern = $this->FixPattern($this->Get('title_pattern'));
    $sSubject = $oEmail->sSubject;

   // Now sanitize $sSubject here to exclude anything you want. You could use preg_replace to get rid of IR-<their amount of numbers if it doesn't change?>
   $sSubject = .... ;

    if(($sPattern != '') && (preg_match($sPattern, $sSubject, $aMatches)))
    {
        $iTicketId = 0;
        sscanf($aMatches[1], '%d', $iTicketId);
        $this->Trace("iTop Simple Email Synchro: Retrieving ticket ".$iTicketId." (match by subject pattern)...");
        $oTicket = MetaModel::GetObject('Ticket', $iTicketId, false);
    }
}

Sometimes you link an IP address to both the interface of a device, but it's the management IP of the CI as well.

Once assigned, IP addresses are not available in the combobox anymore.
While this might be helpful, it might also be undesired.

Same as #3 but for User Request rather than Change.

I think this behavior changed at some point in iTop.

While the impact analysis tab is great, it's annoying that iTop now adds those impacted CIs to the Change's related CIs.

An example: recently I had to add a couple of lines to our firewall configuration. iTop added 600+ items which might be impacted on creating/updating the ticket. However, it was only to open a port. With all those computed CIs added, it makes it more difficult to see what the change was really about.

The only upside to iTop's approach is that you could spot a potential breaking change from any of those impacted CIs. But in a lot of situations, it might be better to manually add them.

This is mostly a copy of iTop's "Add Sample Class" extension, which is used in a tutorial.

However, one important issue has been fixed. If you use the original example, you can create a new monitor CI.

If you want to define a new model, you can do so, but there's no model type "Monitor".
You could select a different model type such as "Peripheral".
But, if you add another monitor CI, same brand, you notice the model you just added for the previous CI won't appear for you to select.

Running an internal helpdesk, people often drop by our desk or we get questions when around a workstation. This adds an option in person to the origin options for a User Request (ITIL).

The most common ports will be added to the Monitor Class. Type: integer.

This would require changes in _ipaddress.class.inc.php.
We won't do that. The tab with CI's pointing to this object, is generated in a PHP-file, not an XML.

Accomplishing it would be:

Find:

				$iNbPCs = 0;
				if  (MetaModel::IsValidClass('PC'))
				{
					if (MetaModel::IsValidAttCode('PC', 'ipaddress_id'))
					{
					$oPCSearch = DBObjectSearch::FromOQL("SELECT PC WHERE ipaddress_id = $iKey");
					$oPCSet = new CMDBObjectSet($oPCSearch);
					$iNbPCs = $oPCSet->Count();
					$iNbCIs += $iNbPCs;
					}
				}

Add:

				/*JB START*/
				$iNbIPDevices = 0;
				if  (MetaModel::IsValidClass('IPDevice'))
				{
					if (MetaModel::IsValidAttCode('IPDevice', 'managementip_id'))
					{
					$oIPDevicesSearch = DBObjectSearch::FromOQL("SELECT IPDevice WHERE managementip_id = $iKey");
					$oIPDevicesSet = new CMDBObjectSet($oIPDevicesSearch);
					$iNbIPDevices = $oIPDevicesSet->Count();
					$iNbCIs += $iNbIPDevices;
					}
				}
				/*JB END*/

Find:

					if ($iNbPCs != 0)
					{
						$oBlock = DisplayBlock::FromObjectSet($oPCSet, 'list');
						$oBlock->Display($oPage, 'pc_id', array('menu' => false));
					}

Add:

					/* JB START */
					if ($iNbIPDevices != 0)
					{
						$oBlock = DisplayBlock::FromObjectSet($oIPDevicesSet, 'list');
						$oBlock->Display($oPage, 'ipdev_id', array('menu' => false));
					}
					/* JB END */

Currently testing and updating the extensions.

Master branch is now based on iTop 2.4.x-releases.
A legacy branch has been created for iTop 2.3.x-compatibility, but it will not receive future updates.

The requirements for this branch will be higher to match iTop 2.4.x-releases, even if it may not be necessary.

It might be better to split the extensions each into their own repository?

They will be easier to be found, downloaded, forked and made patches for it.

What do you think?

Often tickets are marked as resolved while their title has not been changed to anything meaningful.
One needs to re-open the ticket (in our case, triggering notifications) to change the title.

Pro
Better documentation

Con
Currently our PC's are linked to switches already. Patch panels would simply add another CI similar to network device, and complicate things. Rather than PC (port 01) <=> network device (port 01/01), we'd have PC (port 01) <=> patch panel (A1) <=> network device (port 01/01).

It doesn't add much information (location can be defined with for example a PC , patch panel is near the network device ).

Also see https://github.com/cwgueco/itop_modules (only works on iTop 2.1.x )

I just spotted something which is not accurate in my datamodel.

IP Devices - IP Phones should link ConnectableCIs instead of Network Devices.
Somehow this got mixed up. Right now, you can link the IP Phone to a switch, but you can't link the IP Phone to a PC (if IP phone is actually a small switch as well, which is often the case).

The problem is: IP Devices are not necessarily 'datacenter' devices. An IP Phone is both a network device and an end user device as well. I'm also not entirely happy with Network Device being subclassed as a DataCenter device.

This leads to multiple options, both with their ups and downs.

Option 1
We could provide an additional class which mostly imitates lnkconnectablecitonetworkdevice. A new class (and database table) would be needed. We could either make it quite limiting ( lnkconnectablecitoipdevice ) or generic ( lnkconnectablecitoconnectableci ).

Upside: not redefining any other original classes.

Major downside: if you want the link to appear on for example a PC's or other connectable CI's tabs, every one of those classes (or a parent class) needs a redefinition or additional tab.

Option 2
An alternative would be to make our abstract IPDevice class be a child of Network Device. Again, this has undesired effects, since you'd inherit rack options etc. Also, it does not make sense to have IP Camera, IP Phone listed as DataCenter device.

Upside: our IP Devices would be visible on the "Network Devices" tab of for instance a PC.

Major downside: a lot would need to be hidden, which is possible though, especially since I made IPDevice an abstract class with is used by IP Device (generic), IP Camera and IP Phone.

Option 3
Redefining the Network Device, so it's not part of DataCenter class. Question: create a subclass for network switches, to allow for rack options etc? When talking about switches, this might be very useful. When talking about wifi access points, you can have them everywhere in the building, which again questions the definition of 'what is a DataCenter device'.

Upside: actually makes most sense of all.

Major downside: safe for iTop's original IP Phone which never made sense to me (or many others it seems), I'm not in favor of redefining entire classes to change their position in the data model. When done, it's likely to cause quite some head aches to convert everything properly, since I'm sure most of us have used this a lot already.

Other options may be possible as well.

So it's mainly a discussion about the place of DataCenter Device vs Network Device, or other options to consider so you can link all kinds of connectable CIs to IP devices.

IMHO, Option 2 may be the cleanest approach, since our IPDevice class was already based on the Network Device class.

Often steps are already put in Private Logs. You can also see a bit of the history of how solutions were found, or what is not a solution at all.

The formal Solution field does not add anything, since we often keep track of everything in the Private Log. Tickets are not closed right away in quite a few cases, to make sure the issue has effectively been resolved. Copy-pasting the solution does not add anything for us.

Without this adjustment, we just put - in the field.

Current master contains a bug when handling very specific emails. Investigating.

Probably also present in the original Combodo Ticket from eMail extension.

An IP-address is often assigned to a device's interface. (example: network interface of a copy machine).

This makes the IP-address listed as assigned.
When the IP-address is assigned, the actual device no longer lists the IP in the dropdown management IP.

An IP-address can be linked to multiple things.
While sometimes handy, it might be undesired behavior to hide already assigned IP-addresses (be cautious!)

Having 3 organizations on one network, it's difficult to manage IPs in TeemIP.

• Network is shared; yet some devices belong to one of the three organizations (switch A could belong to org A, switch B to org B).
• TeemIP allows you to create a subnet block (let's say we put this on org A); yet org B can't have a subnet which belongs to org A's subnet.
• Say we put all IP's as belonging to org A. If you create switch B, you can't pick the management address.
• Creating the subnet block for both A and B might be an alternative solution, yet new staff will need to be told explicitly to take notice of both organizations IPs.

Another issue: we have some remote locations with a different public ip; but which internally (internet provider) all have a 192.168.x.y address. TeemIP doesn't allow duplicate IPs within an organization.

Update our forked extension to match code changes from Combodo's official version 3.0.7 to 3.0.11 . Document most important changes/new features below.

In recent versions of iTop's official Ticket from email extension it's possible to add other contacts in the email to tickets automatically.

Recently, despite several warnings about this, people continue to send mails to our helpdesk while having other recipients as well (against our guidelines).

While looking at the code of the ticket-from-email extension, there were some things I haven't figured out yet.

• most code is in PHP classes; but when/why do functions get their methods in the Data Model?
• how is 'combodo-email-synchro' vs 'itop-standard-email-synchro' (which requires the first) intended? What's the idea in splitting this up in two extensions?

I was originally planning to contribute some small modifications to the current ticket-from-email extension; but it seems my changes might be going a bit further than I anticipated. So I'm contemplating whether to start from scratch, or just replace one of the two with a version of my own, or perhaps still just stay as close to the original as possible.

The basic idea I have now is to separate actual errors (decoding, failure to create new contacts for unknown callers this was wanted behavior) and policy violations (attachment too big, multiple recipients, no subject, replying to closed ticket...).

For actual errors, a specific person/team/mail address should be able to receive information about the error and the original mail could be attached. Original email could be marked as error or deleted.

For policy violations, it should be the sender who gets told to comply with guidelines. We've been using a precanned reply so far, but I'd like the user to be informed right away, probably using a (case specific) notification instead. (rather than precanned reply, but notification might also just be stored as a property of this mail inbox rather than using the generic 'notifications'/ActionEmail. Original email could be marked as error or deleted.

So I can see some different wanted behaviors for unknown callers. (mark mail as error, just delete mail; forward to someone specific and/or send notification to the unknown caller).

Some might need to be looked into if it's an actual error or a user violation (I noticed something about a Request number which could not be found).7

Another thing to consider: the policies might be shared amongst mailboxes. Little hazzle for users with only one mailbox; yet very handy for cases where multiple mailboxes (or mailbox folders) are scanned.

Trace might get full if you keep it enabled.
Should auto-clear at some point.
Perhaps add config option later.

I think it used to be default behavior in iTop to show all related tickets for a CI.
Anyhow, in my case I want to have quick access to the complete overview of tickets.
This model change takes care of that, so you can for example easily see all issues related to a PC.

I wrote a script to import data from SpiceWorks API (not very well known and not that great) into iTop.

Basically the current version fetches data from SpiceWorks for all PCs and virtual machines in production.
It writes all data from SpiceWorks about the workstations (hardware, selection of software - since SpiceWorks includes way too much information for my taste etc.). You could also retrieve details about your switches (which devices are connected on which port), but those are things I'd like to verify myself.

It's a very basic script right now, which I might share if I remove the sensitive details; and you'd need to adjust it a lot.

I might rewrite it at some point if I figure out how I make it user friendly enough to set up a few things and leave enough options.