Feature #3351

Display phones like emails for users

Added by tsmr almost 8 years ago. Updated over 6 years ago.

Status:NewStart date:02/25/2012
Priority:NormalDue date:
Assignee:webmyster% Done:

0%

Category:Administration
Target version:Candidate for next major version

Description

Like glpi_useremails, add glpi_userphones for use & display multiples phones

And Drop 3 fields : phone, phone2, mobile

Need to tag phone numbers as : mobile / standard / fax / ... ?
Or a dropdown for Phone number type ?

MoYo : which are the impacts on the rest of GLPI ? Which parts need to be review ?
  • Link Phone number with type to user / contact / supplier ?
  • Link to a phone ?

pstn.JPG (33.2 KB) aua, 07/02/2012 08:07 AM

svn.diff Magnifier (14.7 KB) webmyster, 12/16/2012 07:22 AM

History

#1 Updated by walid almost 8 years ago

Having a list of phone number + type would be more flexible
it could also manage SIP phones (see #1088)

#2 Updated by moyo almost 8 years ago

  • Category set to Administration

#3 Updated by jmd over 7 years ago

Téléphone pro
Mobile pro
Téléphone perso
Mobile Perso
Standard
Fax pro
Fax perso
Pager
SIP
Autre

#4 Updated by aua over 7 years ago

Automatic telephone system

First of all, allow to express you our gratitude for your work on development and creation of the useful and unique project (Gestionnaire libre de parc informatique).

During introduction of your product, there were some thoughts on its improvement which we will try to explane below.

The fact of the matter is to input of new object of PBX in GLPI-system intended for the description of system of telephone systems (Privat phone network) including telephone exchanges of PBX (both hardware PBX with FXO/FXS ports, and IP - PBX) thanks to which it will be kept account telephone sets and their connection to PBX and as possibility to exercise control and administration of number space assigned to concrete PBX on concrete port.

At GLPI system operation we came to a conclusion that Computer Network and PSTN Network description practically fit each other. And at the minimum labor costs it is possible to turn Computer Network into PSTN Network where Networking device will be as PBX, and Computer-> Phone. You can see it in Drawing 1.


Drawing 1.

At the moment in GLPI system, telephone sets can be connected to object of Computers and Networking device that doesn't give possibility to describe and make the accounting of phones connected to PBX and as aren't obviously possible for considering and steering telephone numbers. Input of new object of PBX will allow to expand GLPI functional more precisely and fully to consider technical infrastructure.

Understanding that design of a new functional is big work, we want to offer the vision of logic model and its realization within your product of GLPI.

?bject PBX

As it was mentioned above - the object of PBX is a full analog («Networking device») expanded with additional fields.
As well as the most of account objects in GLPI, PBX object in the description should contain two sections. Static section, which contains the general data of the account and dynamic section, that contains descriptions of PBX ports.

Common section
For realization of new PBX object, we suggest to take for a basis object of "Networking device" already available in GLPI, which is suitable by all its function for creation of copies of PBX type object.
In the general part of the description of the registration copy, practically all fields of the description of Networking device correspond to fields of PBX objects:

Port section

The main differences of object of "Networking device" in GLPI system, from PBX object consist in description sections of PBX ports, nevertheless the general principles are similar.

The section of ports should allow to generate specified number of PBX ports similar to creation of Networking device ports in a manual (not automatic) mode, as is shown in Drawing 2.
The description of port should include a sufficient minimum of information (tab 2):

Comment

In this PBX model isn't provided the automatic binding of VOIP Phone to ports of PBX object. VOIP phone as well as any other network device is connected with Networking device port, which already realized in your GLPI system.

?bject «Phone number directory»

Basic parameter of Phone network on which we distinguish her users is phone number.
For the full description of external or internal phone network in GLPI, it is necessary to create the new object of "Phone number directory" comprising all available phone numbers in a network and users for which they are fixed in instance PBX.

«Phone number directory» is virtual object therefore it can be presented in the form of the directory filled by the user or external programs.
To our opinion it should be the table containing a necessary minimum of fields (tab. 3):
Tab. 3
sufficient minimum of information (Tab. 2):

Thus, «Phone number directory» will allow to describe all available space of external and internal telephone numbers in a enterprise’s telephone system.

The indication of communication with a copy of PBX object will simplify communication of phone numbers and their users with PBX ports.

Filling of fields of object of "Phone number directory" is manual, but for convenience of work it would be desirable to provide automatic generation of lines on a sample:
Example of records generation in object: To create 100 records of object of "Phone number directory", on a mask XX-XX, since number 24-00, «PBX-?1» connected with object, with the established sign of "internal".

?bject «Phone»

At the moment, the object of Phone assumes direct connection to object of Computers in the section Direct connections Phone: No phone connected and to object «Networking device» -> network ports -> Connected to : -> Phone
Therefore we suggest to make the following changes:

1. Add Analog or Software Phone or IP sign on which to define availability of the field IP and MAC adress.
2. Change object thus that in case of installation of a sign of item 1 Analog object could connect to PBX. The object can be connected to PBX through phone port, by analogy to Networking device.
Thus are all updates which are necessary for making in the GLPI program for maintaining the accounting of objects of privat phone network.

We understand that the model we described is very simple and doesn't consider many technical nuances of more detailed description of PBX objects, phone or phone network. But in our opinion, its realization will be a reasonable balance between new functionality and spiritual and temporary expenses which you gratuitously spend for development of the GLPI project.
Such simplification will allow you as the developer to define a base functional, and to other members of community to create on its external plugins base.

Functional

A few thoughts on a functional which is necessary to add. As an example there is screenshot of PBX object. This PrtScrn was made of a functional part of object of "Networking device" and changed under a functional of PBX object, see drawing 3.


• At creation of new PBX object, on the mime of standard fields described there should be a possibility to adhere PBX, to FXO/FXS/IP ports above.
• Possibility of fixing of the massif of ports and telephone numbers for PBX from directories. Example:
Port ? 1-1-27-1 (varchar field in a DB) -> Telephone ? 00-01 (varchar field in a DB)
PBX functional, approximately should be similar as is shown in Drawing 4.
• Possibility of fixing of telephone sets to PBX if they are connected through FXO or FXS ports, and for IP phones at you it is already realized, a functional of their addition to Networking device ports.

Here actually all functional which would describe PBX.

Database

In our opinion there won't have to do special changes in database glpidb, having taken as a basis structure of tables for object of "Networking device". In total what will have to make is to expand tables with missing fields for PBX and to create two tables of directories using already ready structure of "Networking device" in glpidb.

Let's try to describe our vision about additions of necessary fields in the tables database of structure of "Networking device".

That is already realized and it isn’t necessary to change it!

1. glpi_networkequipments – this table is completely suitable for creation of PBX object in it.

2. glpi_networkequipmentfirmwares - his table is completely suitable for the insertion of PBX description in it.

3. glpi_networkequipmentmodels – this table is completely suitable for the model description for PBX in it.

4. glpi_networkinterfaces - this table is completely suitable for interface description for PBX (need to add FXO,FXS,IP -types ).

5. glpi_networkequipmenttypes - this table is completely suitable for the description of PBX types (to add such data PBX, PBX).

Condition: if type_PBX = FXO or if type_PBX =FXS then PBX
else type_PBX =IP then PBX

6. glpi_networkequipments – completely satisfies with the structure of PBX and it is not necessary to bring anything else

7. glpi_networkports - completely satisfies with the structure of PBX and it is not necessary to bring anything else. The only thing that is necessary to consider here, to choice of the PBX analog or ip type to give the chance of ports introduction, if to PBX analog: 1-1-27-1 if PBX ip: 10.30.96.1 The functional is shown in Drawing 4.
That is necessary to add!

The only thing that is necessaryto add are 2 tables: Directory of telephone numbers and Directory types of numbers
1. glpi_typenumber –the directory of types of phone numbers External or internal phone number

2. glpi_telephonenumber – directory of telephone numbers

where ID_USERS is id user from database glpidb and the table glpi_users, and ID_TEL-??? id – phone from the table glpi_phones.
In the Fig. 3 it is shown approximate communication of existing tables of glpidb with new tables for PBX object.

#5 Updated by webmyster almost 7 years ago

I'm currently thinking of attaching a "small" subitem (telephone, mail ...) to a bigger one.
For the moment, I have though about : UserEmail, UserTelephone and IPAddress.

From implementation point I view I think that we can deal with CommonDBChild::showAddButtonForChildItem() and CommonDBChild::showFieldsForItemForm().
I can try to work on that.

But for the moment, I don't have any idea of the impact of extracting the telephone field from glpi_users. For instance, it can be used outside and this feature can introduce problem.

#6 Updated by webmyster almost 7 years ago

  • File svn.diffMagnifier added
  • Assignee changed from tsmr to webmyster

I've started to implement my previous post.
For the moment, I don't create UserTelephone class. But I prepare it by normalizing the CommonDBChild's methods and adapt UserEmail to use this mechanisme ...

#7 Updated by moyo almost 7 years ago

Extracting Phone must be specified.
There are different solutions but no choice have been done.

#8 Updated by webmyster almost 7 years ago

Actually, there seems to be two levels of solution for the telephone management.

  1. minimal solution with including UserPhone (cf. NB below) that works same way than UserEmail (ie. CommonDBChild). This is usefull when the administrators don't deals with telephones Phone(s) or to attach external telephone that don't feet inside enterprise Phone system (among others: personnal phones) ;
  2. link solution with User_Phone that inherits of CommonDBRelation. That is usefull to attach a Phone to a User ;

NB: We can imagine to transform UserPhone to ItemPhone and allow attach it to both a User and Phone. That can be usefull to attach several number to a given phone.

Aua: for the moment, I don't have an idea of a smart solution for your requirements. However, implementing PBX seems interesting to implement. I think that we should not mix Network with PBX. Among others, because the signal is not the same (digital vs analogic), the ports are straightly different. Thus, we should integrate a PBX object that differs from the NetworkEquipment.

#9 Updated by moyo almost 7 years ago

  • Target version changed from 0.84 to 0.85

#10 Updated by moyo over 6 years ago

  • Target version changed from 0.85 to Candidate for next major version

Need more specs to be included in a GLPi version

Also available in: Atom PDF