Prevent contradictory solution validation when approving a ticket solution

[andrefelipeufcg]

Hello GLPI community,

We have encountered a recurring situation in our production environment that appears to be more related to usability than to a technical malfunction.

Current scenario

When a technician proposes a solution, the requester can either approve or reject it.

However, some users write comments indicating that the issue is not fully resolved and still click Approve solution.

Example:

"The issue was partially resolved, but I still need access to one remaining feature."

The user then clicks Approve solution instead of Reject solution.

As a result:

• The ticket is closed normally.
• The support team assumes the issue has been resolved.
• No further action is taken.
• The requester's written feedback indicates that additional work is still required.

Why this is problematic

Technically, GLPI behaves correctly because it follows the selected action.

From a usability perspective, however, there is a contradiction between:

• the user's action (approve);
• the user's written feedback (not resolved).

In our environment, this has happened multiple times and required manual intervention.

Possible approaches

This discussion is not intended to request a specific implementation, but rather to explore possible improvements.

Examples:

1. Display a warning when a user enters a comment while approving a solution.
2. Allow administrators to configure whether comments are permitted during approval.
3. Allow administrators to require an empty comment when approving a solution.
4. Provide a hook or extension point for custom validation.
5. Display a confirmation dialog when approval is combined with a non-empty comment.

Local workaround

To mitigate the issue, we implemented a local customization that blocks solution approval when the comment field contains text.

This approach has worked well in our environment because it forces users to either:

• approve the solution without comments; or
• reject the solution and explain what is still pending.

However, we understand that this behavior may not be suitable for all organizations, which is why we believe a configurable solution could be more appropriate.

Has anyone else experienced similar situations?

We would appreciate feedback from the community regarding possible approaches and whether this could be considered a usability improvement for future versions of GLPI.

[andrefelipeufcg]

Hello everyone,

Since I opened this discussion, I decided to go ahead and implement a definitive solution for this usability issue. I have developed a custom plugin called Solution Approval Guard.

The plugin introduces exactly the configurable layer I mentioned in my original post. Administrators can now access a configuration panel and choose between three levels of strictness when a user tries to approve a solution while leaving a comment:

1. Allow: The default GLPI behavior (no interference).
2. Warn: Allows the approval and ticket closure, but displays a yellow warning to educate the user.
3. Block: Aborts the approval process immediately and displays an error message, forcing the user to either clear the text box to approve, or use the "Reject" button instead to report the pending issues.

It is fully compatible with GLPI 11, correctly intercepting both the new Timeline AJAX requests (application/json) and the legacy forms. It also automatically sanitizes empty HTML tags generated by the TinyMCE editor to prevent false positives.

If anyone else is facing this same problem in their production environment, the plugin is open-source and available here:
🔗 https://github.com/andrefelipeufcg/solutionapprovalguard

Feedback, bug reports, and contributions are more than welcome! I hope this helps other organizations maintain the integrity of their ticket closures.