Skip to content

Renaming a container name breaks generated classes and SQL schema #1228

Description

@jhonycertz

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.7

Plugin version

1.24.2

Bug description

Environment

  • GLPI: 11.0.7
  • Fields plugin: 1.24.2
  • PHP: 8.2
  • MariaDB
  • Installed from Marketplace

Description

Changing the Name of an existing container from the GUI breaks generated classes and generated SQL tables.

After renaming the container, saving a Ticket fails because the plugin expects a new generated class that does not exist until files are regenerated.

After regenerating files, the PHP classes are recreated correctly but the generated SQL table is not migrated, resulting in custom field values no longer being saved.

Steps to reproduce

  1. Create a Ticket container.
  2. Set Name to:

RRLL-SF

  1. Add several custom fields.
  2. Save.
  3. Edit the container.
  4. Change only the Name to:

RRHH

  1. Save.
  2. Edit an existing ticket.

Current behavior

The plugin throws:

Attempted to load class PluginFieldsTicketrrhh

Running:

php bin/console plugins:fields:regenerate_files

creates:

ticketrrhh.class.php
ticketrrhhinjection.class.php

However the SQL schema is not regenerated correctly.

The old table remains:

glpi_plugin_fields_ticketrrllsfs

A new table is created:

glpi_plugin_fields_ticketrrhhs

but it only contains:

id
items_id
itemtype
plugin_fields_containers_id
entities_id

None of the generated custom fields are present, therefore values entered in tickets are never stored.

Expected behavior

Changing the container name should either:

  • automatically migrate the generated SQL table and preserve existing data

or

  • prevent renaming if it is not supported.

The generated PHP classes and generated SQL schema should always remain synchronized.

Additional information

Before regenerating files the exception is:

Attempted to load class PluginFieldsTicketrrhh

After regenerating files the exception disappears but custom field values are no longer persisted because the generated SQL table does not contain the generated columns.

I can reproduce this consistently.

Relevant log output

en el inspector lanza esto: POST https://soporte.telecentro.net.ar/front/ticket.form.php?id=2310 500 (Internal Server Error)

Page URL

No response

Steps To reproduce

No response

Your GLPI setup information

  • GLPI: 11.0.7
  • Fields plugin: 1.24.2
  • PHP: 8.2
  • MariaDB
  • Installed from Marketplace

Anything else?

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions