Sometimes, tasks are registered on different days that they were executed. For this reason, it will be nice to have the date field in tasks to put the real task execution date (otherwise it used the current date).

Being able to non-programmatically change field names, hide field names, change the one-line field help text, move fields around on the screen, reorder the <tab> key sequence, and add fields to screens is a common Administrator capability in current generation Asset Management software.

This does not require editing PHP, locales files, or the underlying database, but is done within the application using a visual editor interface via the browser. These changes survive a version upgrade, so need to be considered an overlay to the standard field labels and layout.

The editor allows for changes globally - so that every instance of "User", for example, is changed - or locally to a particular screen only - so "User" in the Computer screen only, for example.

It also supports adding and labeling a small number of 'custom fields' per screen. These custom fields come pre-established within the GLPI database, but remain unused unless the Administrator exposes them. There is a set/known number of them, so there might be:

- 5 * Text Field

- 5 * Numerical Field

- 2 * Dropdown

- 2 * Date

(These are an example only)

The Administrator might then use the Screen Customizer interface to expose (and label) 3 * Text and 1 * Date on a particular screen to capture customized user input. Presenting the captured data is via a customized report(s), but note that manipulating the fields is via code. So, if the Administrator wanted to compare an existing GLPI date field with the customized date field, they would have to write PHP code to do this.

Such a screen customizer would greatly improve the utility of GLPI, by making it easier and faster to tailor the user interface to business requirements. It represents a robust and enduring method of changing the screens that does not force Administrators to risk their operational instance editing code or .po files.

I am currently debugging an issue in regards some emails not being sent.

sent_time appears NULL for  many of the queuednotifications entries and they seem  to stay like that.

For debugging and reporting purposes,I think that  the queued notifications table should also contain the notifications_id information as currently is very hard to know which notification type generated the queued entry.

I think that notifications_id would be more important that notification_template, because we can find out the template from notifications_id but not the other way around.

My idea is to have a shortcut to the global search, as well as the fuzzy search (Ctrl + Alt + G). It could be Ctrl + Alt + F. Or implement all itens search in fuzzy search.

1.estoy integrando glpi y ocsinventory y al instalar las dos aplicaciones no tienen compatibilidad en el php por que ocs inventory utiliza una y glpi otra podria enterarme que version de php pide este aplicativo que estoy implementandolo y si este aplicativo esta en constante evolucion gracias

While you can search for elements in the past, it would be nice to search for future dates.

Ex.

All computers where the warranty ends in the next 12 months from today.

When we create the change from ticket (Create a change from this ticket), the possibility to copy (in addition to title and description) also the requester, the watchers and the assigned peoples.  

1. Update of the case
2. Create case or reassignment
3. New comment
4. Errors
5. New or expired task

3

I'm not an expert php developer but I managed to add support for CAS 3 in glpi in order to access the CAS user e-mail address if available. The idea being that when a user logs in for the first time through CAS, the e-mail adress is automatically retrieved. But I don't know if it breaks compatibility with CAS 2 previously used

I can try to create a PR for this but I'm not sure about the testing part.

I can also provide the diff if that can help, there are not many lines of code

In the company in which I work we are using glpi about a year ago, it is version 9.1.2, it would really be very useful if you glpi in the inventory menus or others display dependent lists, to put a concrete example, suppose there is a phone category in type, in turn this hierarchically should correspond to certain manufacturers and this should reduce the list to choose the model concatenating the above conditions. This would substantially reduce the amount of redundancy in the database and the manual errors that are made when selecting the equipment.

If this idea is already in a thread please let me know to give my support and unify around a single discussion
thank you and I hope this serves somehow