[BUG] Bundled PHPMailer conflicts with GLPI's own PHPMailer

[giovanny07]

#Plugin version: 3.2.6
GLPI version: 11.x
Severity: High
Files: vendor/phpmailer/phpmailer/ (v6.12.0), src/NotificationMail.php

Description

The plugin ships its own copy of PHPMailer 6.12.0 in vendor/phpmailer/ and defines a custom NotificationMail class that extends it directly:

// src/NotificationMail.php
use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\SMTP;

class NotificationMail extends PHPMailer {
    // ...
}

GLPI 11 already bundles PHPMailer as a core dependency (via its own vendor/). When both autoloaders are active, PHP may load either version depending on which autoloader fires first, leading to:

• Class version mismatch errors at runtime.
• Duplicate class definition errors (Cannot redeclare class PHPMailer\PHPMailer\PHPMailer).
• Silent behavioral differences between the two PHPMailer versions.

Furthermore, maintaining a separate mail-sending layer is entirely unnecessary — GLPI 11 provides a complete notification system through NotificationEvent and NotificationTarget that handles all transport concerns (SMTP, queuing, templates, etc.).

Impact

• Runtime fatal errors on environments where autoloader resolution order differs.
• Security: a separate PHPMailer version that may lag behind GLPI's security updates.
• Maintenance overhead: plugin needs to manually update PHPMailer independently of GLPI.
• Binary size: vendor/phpmailer/ adds ~500KB that serves no purpose in GLPI 11.

Proposed fix

Remove the custom mail layer entirely and use GLPI's native notification system.

Step 1 — Delete the custom class and vendor directory:

src/NotificationMail.php         ← delete
vendor/phpmailer/                ← delete (update composer.json accordingly)

Step 2 — Raise events through GLPI's NotificationEvent:

// Wherever NotificationMail was previously used, replace with:
NotificationEvent::raiseEvent('newvalidation', $holiday);
NotificationEvent::raiseEvent('answervalidation', $holiday);

Step 3 — Ensure NotificationTargetHoliday is correctly registered (it already exists at src/NotificationTargetHoliday.php — verify it extends NotificationTarget and implements the required methods for GLPI 11):

// src/NotificationTargetHoliday.php
namespace GlpiPlugin\Activity;

use NotificationTarget;

class NotificationTargetHoliday extends NotificationTarget
{
    public function getEvents(): array
    {
        return [
            'newvalidation'    => __('New holiday validation request', 'activity'),
            'answervalidation' => __('Holiday validation answer', 'activity'),
        ];
    }

    // implement getAdditionalTargets(), addDataForTemplate(), etc.
}

Step 4 — Update composer.json to remove the phpmailer/phpmailer requirement:

{
    "require": {
        "fpdf/fpdf": "^1.86"
    }
}

Additional context

• NotificationTargetHoliday.php already exists in the plugin, meaning most of the infrastructure is in place. The custom NotificationMail class appears to be a legacy workaround from before GLPI's notification system matured.
• GLPI's notification system supports email, browser notifications, and future transports transparently.