Your comments

I'll add: contracts, SLAs ,RSS feed, recurring tickets to the list of parts it sometimes difficult to understand how to handle right.

I agree that we sometimes find ourselves willing to link together 2 plugin or core itemtypes where such link was not anticipated by core/plugin's developer.

+1 on that one.

You might want to wait for GLPI 9.1 which will have an API.

I'm sure user management will be covered (take a look a current development version to make sure it is and suggest it if it is not)

I think Nicolas.quiniou-briand wants that tasks that are "to be done" can be marked as "done" simply by clicking on the (empty) checkbox that currently symbolize this is a "to do" task.

This is a UX improvement.

I'm +1 on this.

A REST API seems to be coming in the next version (built-in, not via a plugin) and could be a base for a CLI.

Built-in REST API sounds good to me :)

Where is that "History window"? An helpdesk ticket's followup?

I am also not fond of (re)enabling stuff when upgrading (I have the same issue with FusionInventory for GLPI and it's import rules).

Maybe the GLPI upgrade wizard could ask the operator whether he wants to:

  • use all the GLPI-default behaviors for notifications (and other customizable stuff)
  • do not change anything: ie. do not enable/disable rules/notifications/behaviors that were disabled/enabled before upgrade

First option would be preferred when testing a new GLPI version (to discover new features/stuff), second one is for when upgrading production.

Thanks for the feature plugin: I'll test it on GLPI v0.90.1...