Hi ,

I'm just getting acquainted with the GLPi world. I have digged documents about my problem but couldn't find .

World is more the Computer asset. Servers, Virtual servers lots of types. I can created those asset types by generic object plugin.

But is it possible to Move an asset from Computer type to (Custom Created) Servers type.

Best Regards

Bahadir

Can't change date format separator.

In current version of GLPI (9.3.3) it is not able to change date format to custom settings (Setup - General - Default values: Date format, or profile - Personalization - Date format). There is only selection of date format from only 3 options:

1. YYYY-MM-DD
2. DD-MM-YYYY
3. MM-DD-YYYY

Problem is especially with separator - (dash) which is not configurable. For example in Slovak/Czech language we use . (dot) as a separator for date and not dash:
29.11.2018

Another languages use / as separator etc.

So it would be great to have option to also change separator for date format.

Describe the solution you'd like

Please add option to change separator for date format. Or better to able to also use custom php format:
http://php.net/manual/en/function.date.php.

For example Wordpress uses 4 predefined options a you can also use your own custom which is great:
https://www.wpbeginner.com/beginners-guide/how-to-change-date-and-time-format-in-wordpress/

As I am working towards training users to build KB Articles in the improved Knowledge Base, There are some custom formatting settings I would like to see used across the board. 

It would be nice if we could create a KB Template per entity so that formatting could be the same when trained technicians create new KB Articles. 

For Example: Default KB Template

(Company Logo)

PLEASE PLACE YOUR KB HEADING HERE 

The body of this knowledge base article should be in italics. Please use this formatting.

We can define unicity on some fields, but their value can still be empty.

On another hand, we may want to set some fields as mandatory; but without any unicity.

Maybe could we consider upgrading the unicity feature to a more generic "fields setup", with unicity and mantadory (at least). Such fields must be marke as required on the html side (using the "standard" * mark, and the relevant html attribute.

Improbe surveys with more questions about of services, etc.

Language by Entity - Define language by entity with more relevant is user language, second is Entity and the last is GLPI Default Language

This will be helpfull for who use GLPI with Anonymous Ticket. When tickets came from specific e-mail address the rule move to specific Entity so the e-mails notifications will be sent following the language of the entity and not from GLPI Default language.

Firstly, thank you for this amazing application.

Please add a template option for 'Problems'. It would be so helpful.

Enable the possibility to sync the dates in the diferent options with google calendar.

Hello,

I am a user of GLPI and I would like to suggest a new feature for version 10: the management of service routes.

This feature would allow fleet managers to plan, optimize and monitor the routes of vehicles and drivers, taking into account factors such as the customer's address, time constraints, tolls, traffic conditions and necessary breaks.

The benefits of this feature would be:

• Cost reduction: route optimization could reduce fuel consumption, vehicle wear and tear, and driver travel time.
• Increased productivity and quality of service: managers could ensure that services were performed in a timely manner and to the expected quality.
• Improved customer and driver satisfaction: customers would be satisfied with the faster and more efficient service, and drivers would be satisfied with the reduced travel time and increased safety of the routes.

The feature could be integrated with the ticket module, so that managers could assign tasks to drivers, track the status of services and generate performance reports. In addition, the feature could be compatible with navigation apps, such as Google Maps or Mapbox, to facilitate driver guidance on routes.

Here are some additional features that the feature could have:

• The ability to relate multiple tickets to a route, in order to group services by proximity, priority or other criteria.
• A route scheduling system, integrated with the GLPI scheduling system, so that managers could define the dates and times of the routes, as well as the time windows for each service.
• The ability to approve routes, so that managers could validate the routes proposed by the system or make manual adjustments, if necessary.
• The definition of technicians, vehicles, the number of seats in the vehicle and other resources needed for each route, in order to ensure the efficiency and safety of operations.

I believe that this feature would be a valuable addition to GLPI, as it would contribute to the improvement of the efficiency and quality of the services provided by companies.

Sincerely,

Eduardo Spinola

Olá,

Sou um usuário do GLPI e gostaria de sugerir uma nova funcionalidade para a versão 10: o gerenciamento de rotas de atendimento.

Essa funcionalidade permitiria aos gestores de frotas planejar, otimizar e monitorar as rotas dos veículos e dos motoristas, levando em conta fatores como o endereço do cliente, as restrições de horário, os pedágios, as condições de tráfego e as pausas necessárias.

Os benefícios dessa funcionalidade seriam:

• Redução de custos: a otimização das rotas poderia reduzir o consumo de combustível, o desgaste dos veículos e o tempo de deslocamento dos motoristas.
• Aumento da produtividade e da qualidade dos atendimentos: os gestores poderiam garantir que os atendimentos fossem realizados no tempo adequado e com a qualidade esperada.
• Melhoria da satisfação dos clientes e dos motoristas: os clientes ficariam satisfeitos com o atendimento mais rápido e eficiente, e os motoristas ficariam satisfeitos com a redução do tempo de deslocamento e a maior segurança das rotas.

A funcionalidade poderia ser integrada com o módulo de tickets, para que os gestores pudessem atribuir as tarefas aos motoristas, acompanhar o status dos atendimentos e gerar relatórios de desempenho. Além disso, a funcionalidade poderia ser compatível com aplicativos de navegação, como o Google Maps ou o Mapbox, para facilitar a orientação dos motoristas nas rotas.

A seguir, são apresentadas algumas características adicionais que a funcionalidade poderia ter:

• Possibilidade de relacionar vários tickets a uma rota, de forma a agrupar os atendimentos por proximidade, prioridade ou outros critérios.
• Sistema de agendamento de rotas, integrado ao sistema de agendamento do GLPI, para que os gestores pudessem definir as datas e os horários das rotas, bem como as janelas de tempo para cada atendimento.
• Possibilidade de aprovação das rotas, para que os gestores pudessem validar as rotas propostas pelo sistema ou fazer ajustes manuais, se necessário.
• Definição dos técnicos, dos carros, do número de vagas no carro e de outros recursos necessários para cada rota, de forma a garantir a eficiência e a segurança das operações.

Acredito que essa funcionalidade seria uma valiosa adição ao GLPI, pois contribuiria para a melhoria da eficiência e da qualidade dos atendimentos prestados pelas empresas.

Atenciosamente,

Eduardo Spinola

Hello, I would like to suggest an improvement in the location part of GLPI, which allows to define if a location can be related to a ticket or not. The goal is to force the user to choose the most specific location, especially when using multiple hierarchical levels of location, such as city > branch x > floor > room.

This would facilitate the management of tickets, avoiding that the user chooses a generic or incorrect location, and allowing to filter tickets by location more easily. It would also help to avoid unnecessary trips or surprises when attending a ticket in a certain location.

I believe that this functionality would be useful for many users of GLPI, and I hope that it can be implemented in a future version. 

Thank you for your attention.

#######################$$$

Título: Permitir definir se uma localização pode ser relacionada a um chamado ou não

Texto:

Olá, eu gostaria de sugerir uma melhoria na parte de localização do GLPI, que permita definir se uma localização pode ser relacionada a um chamado ou não. O objetivo é poder forçar o usuário a escolher a localização mais específica, em especial quando se utilizam vários níveis hierárquicos de localização, exemplo cidade > filial x > andar > sala.

Isso facilitaria o gerenciamento dos chamados, evitando que o usuário escolha uma localização genérica ou incorreta, e permitindo filtrar os chamados por localização mais facilmente. Também ajudaria a evitar viagens desnecessárias ou surpresas ao atender um chamado em uma determinada localização.

Eu acredito que essa funcionalidade seria útil para muitos usuários do GLPI, e espero que ela possa ser implementada em uma versão futura.

Obrigado pela atenção.