TeemIp's IP Request Management extension allows you to manage user requests that are specific to IP management: IP and subnet creations, modifications or deletions. It includes a user portal where standard users can create and manage their IP requests.
Version | Release Date | Status | iTop Min | IPAM for iTop Min | Comments |
---|---|---|---|---|---|
3.1.2 | 2024-08-14 | Supported | 3.0.0 | 3.1.0 | - TeemIp / iTop 3.2 and PHP 8.3 compatible version |
3.1.1 | 2023-12-11 | Supported | 3.0.0 | 3.1.0 | - Add Chinese (simplified) translation |
3.1.0 | 2023-06-21 | Obsolete | 3.0.0 | 3.1.0 | - Process menu has moved with other actions - Markup HTML has been added on key attributes - XML structure has moved to 3x |
3.0.1 | 2022-09-09 | Obsolete | 2.7.0 | 3.0.1 | - Adopt 3.x icon style |
3.0.0 | 2022-01-10 | Obsolete | 2.7.0 | 3.0.0 | - TeemIp / iTop 3.x compatible version |
2.7.1 | 2021-04-01 | Obsolete | 2.7.0 | 2.7.0 | - Allow automatic request processing for some profiles. - Add a group of recently created requests in Portal list of ongoing tickets. - Align extension structure with new guidelines. |
2.6.1 | 2020-05-08 | Obsolete | 2.7.0 | 2.6.0 | - Revision for TeemIp 2.6.1 |
2.6.0 | 2020-04-14 | Obsolete | 2.7.0 | 2.6.0 | - Revision for TeemIp 2.6.0 |
2.5.1 | 2019-12-10 | Obsolete | 2.6.0 | 2.5.0 | - Revision for TeemIp 2.5.1 - Includes TeemIp portal from now on |
2.5.0 | 2019-09-24 | Obsolete | 2.6.0 | 2.5.0 | - Revision for TeemIp 2.5.0 |
2.4.0 | 2019-02-09 | Obsolete | 2.5.0 | 2.4.0 | - Revision for TeemIp 2.4.x |
2.3.0 | 2018-08-28 | Obsolete | 2.5.0 | 2.3.0 | - Revision for TeemIp 2.3.x |
2.1.2 | 2017-11-11 | Obsolete | 2.3.0 | 2.2.0 | - Revision for TeemIp 2.2.0 |
2.1.1 | 2016-12-19 | Obsolete | 2.1.0 | 2.1.1 | - Revision for TeemIp 2.1.1 |
This extension allows Hostmasters to manage tickets that are specific to the IP management world: creation, modification or release of IPs, creation, modification or release of subnets.
Management of IP tickets is done following a workflow that automates the standard tasks associated to IP tickets: selection of an IP within a subnet, selection of a subnet within a subnet block, for instance. Such workflow insures that tickets are managed according to a defined process. Only authorized users can manage an IP request and change its status. Full automation is also available to the end users who have the correct profile and for subnet blocks or subnets that allow such comprehensive automation.
At any time of the life of the ticket, the support agent can communicate with the customer via a “Public log.” He can also communicate with teams internal to his company through a “Private log”.
TeemIp IP Request Management includes a dedicated portal that is described here.
The TeemIp Request Management extension is licensed under the terms of the GNU Affero General Public License Version 3 as published by the Free Software Foundation. This gives you legal permission to copy, distribute and/or modify TeemIp Request Management under certain conditions. Read the ’license.txt’ file in the TeemIp distribution. TeemIp Request Management is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE WARRANTY OF DESIGN, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE.
The module handles requests for IPs and Subnets but not for IP blocks nor IP ranges.
There is no specific requirements with TeemIp standalone as TeemIp Request Management is already embedded in it.
When installed on an iTop application, make sure that 'IPAM for iTop' is installed as well.
Installation on a TeemIp standalone is done with the application itself.
When adding the module on an iTop application, the process will depends on the iTop version:
No specific configuration is required in TeemIp's configuration file. However, 2 parameters may be adjusted in the Global IP settings, under the “Default Settings for IP Requests” block.
Parameter | Meaning | Sample value |
---|---|---|
Offset for the creation of IPs within IPv4 subnets | Used when IP are automatically picked within an IPv4 subnet | |
Offset for the creation of IPs within IPv6 subnets | Used when IP are automatically picked within an IPv6 subnet |
Once installed, the module will add a menu group called IP Helpdesk where IP requests will be managed from.
The overview dashboard allows agents and managers to monitor the helpdesk activity. It displays a set of 6 dashlets:
IP requests in TeemIp are focusing on IP management. A catalogue of 6 types of IP requests have been defined, each of them focusing on a specific request:
IP request properties shows information that is standard between all types of IP requests and information that is specific to each IP request.
Name | Type | Mandatory? |
---|---|---|
General Information | ||
Ref | Ticket's ID - Automatically calculated | Yes |
Title | Alphanumeric string | Yes |
Organization | Foreign key to a(n) Organization | Yes |
Status | Possible values: New, Rejected, Assigned, Resolved, Closed | Yes |
Description | Multiline character string | Yes |
Contacts | ||
Caller | Foreign key to a(n) Person | Yes |
Team | Foreign key to a(n) Team | Yes* |
Agent | Foreign key to a(n) Person | Yes* |
Dates | ||
Start date | Date and time (year-month-day hh:mm:ss) | No |
Last update | Date and time (year-month-day hh:mm:ss) | No |
Close date | Date and time (year-month-day hh:mm:ss) | No |
User comment | Multiline character string | No |
Name | Type | Mandatory? |
---|---|---|
IP Informations | ||
Subnet Block | Foreign key to a(n) IPv4 Subnet Block | No |
Subnet | Foreign key to a(n) IPv4 Subnet | No |
Range | Foreign key to a(n) IPv4 Range | No |
Location | Foreign key to a(n) Location | No |
IP Status | Possible values: allocated, reserved | No |
Short Name | Alphanumeric string | No |
DNS Domain | Foreign key to a(n) Domain | No |
Usage | Foreign key to a(n) IP Address Usage | No |
Device Information | ||
Target class | Instantiated class of object that the IP should be linked to | No |
Functional CI | CI of class “Target class” which the IP address should be allocated to | No |
CI's IP attribute | IP attribute of the CI that the IP should be allocate to | No |
Name | Type | Mandatory? |
---|---|---|
IP Informations | ||
Subnet Block | Foreign key to a(n) IPv6 Subnet Block | No |
Subnet | Foreign key to a(n) IPv6 Subnet | No |
Range | Foreign key to a(n) IPv6 Range | No |
Location | Foreign key to a(n) Location | No |
IP Status | Possible values: allocated, reserved | No |
Short Name | Alphanumeric string | No |
DNS Domain | Foreign key to a(n) Domain | No |
Usage | Foreign key to a(n) IP Address Usage | No |
Device Information | ||
Target class | Instantiated class of object that the IP should be linked to | No |
Functional CI | CI of class “Target class” which the IP address should be allocated to | No |
CI's IP attribute | IP attribute of the CI that the IP should be allocate to | No |
Name | Type | Mandatory? |
---|---|---|
IP Informations | ||
IP Address | Foreign key to a(n) IPv4 or IPv6 address | Yes |
New IP Status | Possible values: allocated, reserved | No |
New Short Name | Alphanumeric string | No |
New Domain | Foreign key to a(n) Domain | No |
New Usage | Foreign key to a(n) IP Address Usage | No |
Name | Type | Mandatory? |
---|---|---|
IP Informations | ||
Subnet Block | Foreign key to a(n) IPv4 Subnet Block | Yes |
Mask | Possible values: from /16 down to /32 | Yes |
Name | Alphanumeric string | No |
Subnet Status | Possible values: allocated, reserved | Yes |
Type | Alphanumeric string | No |
Location | Foreign key to a(n) Location | No |
Name | Type | Mandatory? |
---|---|---|
IP Informations | ||
Subnet Block | Foreign key to a(n) IPv6 Subnet Block | Yes |
Mask | Possible values: /64 down to /128 | Yes |
Name | Alphanumeric string | No |
Subnet Status | Possible values: allocated, reserved | Yes |
Type | Alphanumeric string | No |
Location | Foreign key to a(n) Location | No |
Name | Type | Mandatory? |
---|---|---|
IP Informations | ||
Subnet to update | Foreign key to a(n) IPv4 or IPv6 Subnet | Yes |
New Name | Alphanumeric string | No |
New Subnet Status | Possible values: allocated, reserved | No |
New Type | Alphanumeric string | No |
Old Location | Foreign key to a(n) Location | No |
New Location | Foreign key to a(n) Location | No |
Tab | Description |
---|---|
Contacts | All the contacts linked to this ticket |
Attachements | Documents attached to the ticket |
By default, IP request management is restricted to the IP Helpdesk agent profile that is defined with TeemIp.
From the Helpdesk menu, click on the “New IP Request” link. User is then asked to select amongst the 6 types of requests:
Once selection is done, the creation form is displayed (IPv4 subnet creation, in the example below).
The public and the private log are used to keep track of all communications and activities related to a user request.
The public log is aimed at exchanging information with the requestor.
The private log is the preferred way for keeping track of the investigations or operations: copy/paste of command line results, summary of communications with a provider, etc.
Each entry in the public or private log is tracked with the name of the user who updated it and when it was done. It cannot be modified nor deleted.
The public log is visible from the TeemIp customer portal.
Once an IP request is created, it needs to be assigned to a team and agent before being further processed. For that to happen, select the Assign action in the list of menus available from the details page.
Then select the Support team you want to assign the ticket to, as well as the agent from this team.
Once an IP request is assigned, the agent in charge of the request can process it. This task will actually be performed by TeemIp itself which will autonomously offer the agent to choose amongst a list of IPs or subnets for new IP or a new subnet creations or to directly perform the required change for IP or subnet modification or release.
When the Process action of an IPv4 or IPv6 creation is launched, TeemIp will look for the first 10 free IPs located in the subnet, from an IP offset defined in the Global IP Setings, and will list them at the top of the request.
Once the IP is selected, pressing the “Process” button will create the IP in the data base with the attributes set in the request and, if a Functional CI has been selected and one of its IP Address attributes chosen, will update the CI's attribute with the newly created IP address. At the same time, the ticket is put in the Resolved state.
If the agent wants to give a specific IP address that already exists in TeemIp's data base, then he needs to press the Modify button instead of the Process one and select the right IP in the IP Address field of the ticket. Once done, the ticket still needs to be processed in order to move the ticket to the Resolved state.
Launching the Process action on an IP address update ticket will simply modify the IPattributes that have been set in the request without changing the others.
Processing an IP address release request will set the IP in the released state and the Release date attribute to the current date and time.
When the Process action of an v4 or v6 subnet creation is launched, TeemIp will look for the first 10 free subnets in the predefined block and will list them at the top of the request.
Once the subnet is selected, pressing the “Process” button will create the subnet in the data base with the attributes set in the request. At the same time, the ticket is put in the Resolved state.
If the agent wants to give a specific subnet that already exists in TeemIp's data base, then he needs to press the Modify button instead of the Process one and select the right subnet in the Subnet created field of the ticket. Once done, the ticket still needs to be processed in order to move the ticket to the Resolved state.
Launching the Process action on a Subnet update ticket will simply modify the subnet attributes that have been set in the request without changing the others.
If some complex change (like subnet resizing) has been asked through the Description field of the request, then the agent in charge of the request will need first to apply the change through the standard subnet management tools provided by TeemIp before processing the request. Note that no specific check is done within TeemIp to make sure that such action has been done prior moving the ticket to Resolved state.
Processing a Subnet release request will set the subnet in the released state and the Release date attribute to the current date and time.
A new profile has been defined : IP Portal Automation user which must be used in conjunction with IP Portal user profile. Portal users with this profile have their IP requests automatically processed:
When processed a message is copied into the public log, explaining to the end-user that his ticket has been automatically processed thanks to your privileges. And once complete, the request is automatically moved to the resolved state.
For creation requests, the subnet or the subnet block, where the IP or subnet are supposed to be picked from, need to be eligible for automatic creation. This behaviour is driven buy a parameter named “Allow automatic subnet creation” / “Allow automatic IP creation” added to the subnet blocks and subnets. Default is “yes”.
All IP requests share the same life cycle. This one is pretty simple and can be summarized as follows:
The IP Request management module works in conjunction with TeemIp portal, named IP Portal, that is embedded in the extension since revision 2.5.1. Please, refer to the portal documentation page for further details on it.
TeemIp incorporates Combodo extension “Send updates by email” which allows to send an email when updating the public log or the private log of an IP Request, thus allowing support agents to communicate with the callers directly by updating either the public log or the private log of the ticket. Attachments added while editing the ticket are automatically sent as attachments to the email. The user can select the attachments to be sent with the message. Newly added attachments are automatically selected but can be manually deselected if needed.
The configuration relies on a specific type of Trigger (“on log update”) and the usual Email Actions. The definition of the Trigger object determines which field of the ticket (public_log, private_log…) is used for the feature.
For a comprehensive description of that feature, please refer to its wiki here.