Skip to content

Rule Clone Fails When Orphan Tags Exist #332

@boraergul

Description

@boraergul

Code of Conduct

  • I agree to follow this project's Code of Conduct

Is there an existing issue for this?

  • I have searched the existing issues

GLPI Version

11.0.4

Plugin version

2.14.3

Bug description

When using the Tag plugin with GLPI 11.0.4, cloning rules (via Massive Actions or UI clone) fails with a server error if there are tags defined that are not associated with any items.

Disabling the Tag plugin immediately resolves the issue.

This indicates the plugin does not safely handle orphan tag records during relation cloning.

Relevant log output

[2026-02-12 11:49:50] glpi.CRITICAL: *** Uncaught PHP Exception RuntimeException:
"Cannot guess field for itemtype Rule on RuleAction"
at /var/www/glpi/src/CommonDBChild.php line 1039

Backtrace:
#0 /var/www/glpi/src/CommonDBChild.php(1039): CommonDBChild::getItemField()
#1 /var/www/glpi/src/Glpi/Features/Clonable.php(121): CommonDBChild->getItemField()
#2 /var/www/glpi/src/Glpi/Features/Clonable.php(299): Rule->cloneRelations()
#3 /var/www/glpi/src/Glpi/Features/Clonable.php(229): Rule->clone()
#4 /var/www/glpi/src/MassiveAction.php(1599): Rule->cloneMultiple()
#5 /var/www/glpi/src/MassiveAction.php(1313): MassiveAction::processMassiveActionsForOneItemtype()
#6 /var/www/glpi/src/MassiveAction.php(1291): MassiveAction->processForSeveralItemtypes()
#7 /var/www/glpi/front/massiveaction.php(63): MassiveAction->process()
#8 /var/www/glpi/src/Glpi/Controller/LegacyFileLoadController.php(64): require()
#9 /var/www/glpi/vendor/symfony/http-kernel/HttpKernel.php(181): LegacyFileLoadController->__invoke()
#10 /var/www/glpi/vendor/symfony/http-kernel/HttpKernel.php(76): HttpKernel->handleRaw()
#11 /var/www/glpi/vendor/symfony/http-kernel/Kernel.php(197): HttpKernel->handle()
#12 /var/www/glpi/public/index.php(70): Kernel->handle()


Browser console:


POST https://<glpi-url>/front/massiveaction.php 500 (Internal Server Error)

Uncaught SyntaxError:
Identifier 'GlpiCommonAjaxController' has already been declared

Page URL

https:///front/rulemailcollector.php

Steps To reproduce

Install and enable Tag plugin
Create one or more Tags
Do NOT associate those tags with any items
Go to:
Administration → Rules → RULES FOR ASSIGNING A TICKET CREATED THROUGH A MAILS RECEIVER

Attempt to clone a rule

via selecting it than Actions → Clone

Your GLPI setup information

GLPI Version: 11.0.4
Tag Plugin: https://github.com/pluginsGLPI/tag
Database: MariaDB 10.11.11
OS: Debian 12

Anything else?

Expected Behavior
Rule cloning should complete successfully, regardless of whether unused tags exist.
Unused tags should be ignored by relation cloning.

Actual Behavior
Clone operation fails:

UI shows:
An unexpected error occurred

Browser console:
POST front/massiveaction.php 500 (Internal Server Error)

GLPI logs:
Uncaught PHP Exception RuntimeException:
"Cannot guess field for itemtype Rule on RuleAction"
at CommonDBChild.php line 1039

Backtrace excerpt:
CommonDBChild::getItemField()
Rule->cloneRelations()
Rule->clone()
MassiveAction->process()
Root Cause Observation

The issue occurs only when orphan tags exist:

Tags present BUT No entries in plugin_tag_items relation table
After removing orphan tags, cloning works immediately.

Also reproducible:
Creating orphan tag again
Clone fails again
This strongly suggests the plugin injects relations into clone handling but does not validate relation integrity.

Temporary Workaround

Either: Disable Tag plugin OR Remove orphan tags manually:

Suggested Fix Direction
Plugin should:
Gracefully ignore tags without item relations
Validate relation existence before clone processing
Avoid injecting invalid relation metadata

Impact
Breaks Rule cloning functionality
Causes HTTP 500
Affects UI and Massive Actions
Hard to diagnose without deep log inspection
This can disrupt production workflows.

Additional Notes

This behavior was reproduced with:
API-created rules
Manually created rules
Multiple rule types

So the issue appears independent of rule origin.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions