Summary: Enhance project visualization by introducing the ability to assign custom colors to projects, tasks, and milestones based on their Project Type. The selected colors should be reflected in both the project table view and the GANTT plugin for improved clarity and visual distinction.

Details:

1. Color Customization:
• In the Project Type definition, alongside the Name and Comments fields, add three color pickers labeled "Project color," "Task color," and "Milestone color."
  
2. Table View Enhancement:
• Display the selected "Project color" in the project table view, surrounding the type of the project, similar to the display of Project Priority.
  
3. GANTT Plugin Integration:
• Utilize all three colors in the GANTT plugin view: "Project color" on the project bar, "Task color" on the task bar, and "Milestone color" on the milestone symbol.

BeyondTrust Remote Support is an HelpDesk tool, to connect to remote machines securely.

16.000 installations in the world, some of the customers use also GLPI.

It could be a good option to connect directly from a ticket to the machine.

An extended API exists in Remote Support to start this connection.

Possibility of sharing pre-designed Filters/Markers between users

Good morning, the possibility of being able to share among selected nominative users the different filters/Bookmarks that are created as predefined queries is suggested. Currently, they must be made public to all personnel who use GLPI or private. It would be useful to be able to share it among selected users of the same team, etc. so you don't have to create the same query for different logins in a custom way.

Thanks in advance.

In the real world it is simply impossible to teach all staff and costumers to always remove automaticially addded information  above the delimter line (i.e. Outlook's automaticially added "From, Sent, To, Topic"-Lines, the so called Outlook-Header).

If such auto-added information is not manually removed prior sending the mail to glpi, the tickets will look very confusing and further notifications mails will become litterally unreadabble due to all the content segmentation in the mail-body. This renders the Ticketsystem unusuable in some use cases (i.e. wehere mail is the most choosen way for ticket-creation and follow ups).

Therfore we have demand to simply deactivate this content-stripping on incoming mails and with that the insertion of delimter-lines in the outgoing mails. In the best case there will be an button to activate/deactivate content-stripping and delimter lines.

It is cllear, that the tickets can have multiple qoutes multiple times then, but after all, the ticket and notification-mails will stay redable and understandable. This kind of behavior is used by other systems like OTRS and is of course widley accepted by admins and users.  

Integrate rustdesk with glpi

Get rustdesk ID from glpi agent or add manually

Open rustdesk when click on ID URL Rustdesk 

Enable notifications queue through API request. So we can monitor how many notifications that can be error-related.

Generate ticket after change of the hardware collected by glpi agent

We diligently use your excellent certificate tracking tool and the knowledge base tool.

As part of the management of renewal and follow-up of certificates, we have procedures to help with renewal. For this, we use an entry from the knowledge base.

Unfortunately, when managing domains, we cannot associate a knowledge base entry to it.
When managing domain records, we cannot associate certificates, knowledge bases or associated items to it.

Would it be possible to activate these modules on the pages concerned?

(Here is a request that might look like this request. ticket )

Best regards

source ticket:https://github.com/glpi-project/glpi/issues/14891

We've seen that we can associate tickets and other types to a ticket. But how to distinguish e.g., between a change that was a result of a ticket and a ticket because of a change? 

One can associate changes in tickets but there is no indication if the change was the result or the (root) cause of the ticket.

Wouldn't it be a useful idea, to specify the cause of a ticket? And causes could be changes (most likely), or other objects like project tasks, release, etc.

Also, in the solution-entry one can specify a solution type but no relation to a type (e.g. a change). 

Wouldn't it be a useful idea, to specify the solution of a ticket and link the "solving" item (e.g. a change)?

Hello, it will be very helpfull to have a export to XML of the assets. This can provide to export asset to a monitoring application (for example Zabbix). Thank