Nice project manager in 0.90.1, but non tree view and this bad...
Subprojects in all list view no good idea

source: https://github.com/glpi-project/glpi/issues/317

If a wiki was available I could update procedures because on the website many procedure are obsoletes.

When we add a business rule, on Actions we can assign "Very high", 'high'... priority but we cannot assign the "Major" priority

Most organization use some form of Web application such as OWA, WordPress, Joomla or GLPI.

The Web applications plugin allows tickets to be associated with the web application.

The last few releases for the Web applications plugin fail to support association of ticket which is the most required feature of the plugin.

Integrating the Web applications plugin would allow myself and others to upgrade to the current version of GLPI rather than being held back.

I'm suggesting the fact that GLPI could keep track of the significant events a Computer/Phone/NetworkEquipment/Printer/Room/etc suffered or gained of. The goal is to offer a clear view of what happened to it.

Examples:

For a computer:

* Computer was acquired

* OS was installed

* Faulty RAM was replaced

* HDD was "upgraded" for a SSD

* OS was reinstalled

For a Network equipment:

* Switch was acquired

* Faulty fan was replaced

* Firmware was upgraded

I must admit the initial need that made me think about this feature is for computers. Because they are pieces of hardware that "lives" the most and are what users are the more sensible to (it's what they use everyday and it's shape determine their mood/user experience), I need a digest of bad and good things that were done to it, so that I can determine if the whole computer should be replaced or if a OS re-installation could improve the user experience.

Implementation could rely on tickets with a simple "Significant event?" checkbox.

The "x was acquired" event could use financial and administrative informations from the "Management" tab.

Theses events shall be listed on a dedicated "Significant event" tab ordered by date.

I'm not sure the need is strong enough for a core integration so it'll be a plugin.

I have a business rule that assign a technician group by category, for add and update. The group is added but i want change it.

Thanks in advance.

Current situation:

Currently, GLPI supports various network port types (Ethernet, Wifi, Port Aggregation, Alias, Dialup, Loopback, Fibre Channel). However, there is no dedicated type for PON (Passive Optical Network) technologies like GPON, XGS-PON, or EPON.

Why it's needed: With the massive growth of FTTH (Fiber to the Home) and POL (Passive Optical LAN) deployments, managing equipment like OLTs (Optical Line Terminals) and ONTs/ONUs (Optical Network Units) in GLPI is difficult using only the "Ethernet" or "FC" types. PON ports behave differently – they are point-to-multipoint and require specific attributes.

Proposed change:

1. Add PON as a new entry in the Network Port type dropdown.
2. (Optional but recommended) Allow adding specific attributes for this port type, such as:
   • Optical Power (TX/RX)
   • ONT ID / ONU ID
   • VLAN Configuration (Service/Management)
   • Splitter Ratio

Benefit: This will allow network administrators and ISPs to accurately document modern fiber-optic infrastructure within GLPI without using "workarounds" or generic port types.

Currently, this lack of a dedicated PON type significantly impacts the GLPI Inventory module. When using the GLPI Agent to discover and import network equipment (such as OLTs or high-end routers), all fiber-optic interfaces are automatically classified under the generic 'Ethernet' type.

This creates several issues:

• Data Inconsistency: Network administrators cannot easily filter or report on actual fiber infrastructure vs. copper connections.
• Manual Overhead: After every synchronization, users have to manually correct the port types to reflect the real-world physical layer, which defeats the purpose of automated inventory
• Improper Mapping: Standard Ethernet attributes don't always align with PON-specific logic (like shared bandwidth or passive splitting), leading to a messy documentation structure.

Integrating PON as a native type would allow the GLPI Agent to correctly map these interfaces during the XML/JSON import phase, ensuring that the CMDB remains a 'Single Source of Truth' without constant manual intervention.