Forum GLPI-Project

Jem7734

Member

Registered: 2024-08-12

Posts: 5

[Solved] The Business Rule does notaddor assign morethanone specialist

Sorry in advance for bad English.

Good afternoon. Recently updated from version 9.4.4 to 9.5.13. The update process was successful. But when I launched GLPI, after a while I received a remark from my colleagues that the "Business Rules" partially work.
   
Problem encountered: When filling out an application, when a regular user (with a profile: "post-only", who can only create and view their applications) selects the "Category" he needs, the "business rule" should have been executed, which "Assigns" and "Adds" 3 or more specialists and observers. But in the end, only one is “Assigned” and “Added” for each action. This problem was not observed in the old version of GLPI (version: 9.4.4).

To reproduce the bug:
   
        1. Create a simple business rule;
                   

        2. Set the criterion by which specialists and observers will be appointed:
                   

        3. Inside the rule, on the "Action" tab, add a "Group of specialists", specialists and wathers:
                   

        4. Create a ticket from the "post-only" profile:
                   

        5. Result:
                  - Out of 5 specialists, only 1 was "Add" and "Assign";
                  - Out of 3 observers, only 1 was "Add" and "Assign".
                   

P.s. Please do not write in the spirit of "Update to the new version 10.0.16 and higher." I specifically need this version! Because We are not yet ready to upgrade to version 10.0.x. If you cannot offer an option with theoretical problems, then at least indicate what financial opportunities are provided by the “Assignment” and “Addition” specialists and observers.

Thanks for your answer in advance!

Last edited by Jem7734 (2024-08-15 15:15:56)

Jem7734

Member

Registered: 2024-08-12

Posts: 5

Re: [Solved] The Business Rule does notaddor assign morethanone specialist

Good afternoon. I would like to get at least some answer. For example, “Since support for GLPI version 9.5 was discontinued in 2023, it is not processing applications,” “We cannot help with this,” “The application has been accepted,” etc.
Or, as I wrote earlier, please write in which php files you need to make changes in order to try to fix the error yourself.

Jem7734

Member

Registered: 2024-08-12

Posts: 5

Re: [Solved] The Business Rule does notaddor assign morethanone specialist

Does this guide apply to version 9.5?

Wrote without "https://": glpi-developer-documentation.readthedocs.io/en/master/devapi/rules.html

cconard96

Moderator

Registered: 2018-07-31

Posts: 2,809

Website

Re: [Solved] The Business Rule does notaddor assign morethanone specialist

The developer documentation applies to the current supported version, but the rules engine hasn't really changed in the last several versions so that specific page should still apply.

---

GLPI Collaborator and Plugin Developer.
My non-English comments are automated translations. Sorry for any confusion that causes.
Mes commentaires non anglais sont des traductions automatiques. Désolé pour toute confusion qui cause.
Mis comentarios que no están en inglés son traducciones automáticas. Perdón por cualquier confusión que cause.

Jem7734

Member

Registered: 2024-08-12

Posts: 5

Re: [Solved] The Business Rule does notaddor assign morethanone specialist

Found the reason for the problem.
I performed the actions described above. Then I went to php-errors.log (Path: "/var/www/glpi/files/_log/"). I saw an error there:

[2024-08-13 14:27:24] glpiphplog.WARNING:   *** PHP Warning (2): Array to string conversion in /var/www/glpi/inc/commonitilobject.class.php at line 2244
10017073  Backtrace :
10017074  inc/commonitilobject.class.php:2244                array_unique()
10017075  inc/commonitilobject.class.php:2148                CommonITILObject->addAdditionalActors()
10017076  inc/ticket.class.php:1931                          CommonITILObject->post_addItem()
10017077  inc/commondbtm.class.php:1177                      Ticket->post_addItem()
10017078  front/tracking.injector.php:63                     CommonDBTM->add()

I went into the commonitolobject.class.php file and scrolled to line 2244. Since I don’t know anything in the code, I started comparing 2 versions of GLPI (9.5.7 and 9.5.8. Since I tested many different versions, I noticed that when switching from 9.5.7 to 9.5.8 I start to catch this bug).

After comparing in the files commonitilobject.class.php I saw that the code was added:

$actor_fields = [
         'Group' => [
            [
               'name' => '_additional_groups_requesters',
               'type' => CommonITILActor::REQUESTER
            ],
            [
               'name' => '_additional_groups_observers',
               'type' => CommonITILActor::OBSERVER
            ],
            [
               'name' => '_additional_groups_assigns',
               'type' => CommonITILActor::ASSIGN
            ],
         ],
         'Supplier' => [
            [
               'name' => '_additional_suppliers_assigns',
               'type' => CommonITILActor::ASSIGN
            ],
         ],
         'User' => [
            [
               'name' => '_additional_requesters',
               'type' => CommonITILActor::REQUESTER
            ],
            [
               'name' => '_additional_observers',
               'type' => CommonITILActor::OBSERVER
            ],
            [
               'name' => '_additional_assigns',
               'type' => CommonITILActor::ASSIGN
            ],
         ],
      ];
      $existing_users = $useractors->getActors($this->fields['id']);
      $existing_groups = $groupactors->getActors($this->fields['id']);
      $existing_suppliers = $supplieractors->getActors($this->fields['id']);

      /**
       * @var string|CommonDBTM $actor_type
       * @var array $actor_fields
       */
      foreach ($actor_fields as $actor_type => $fields) {
         // Remove duplicate actors from field inputs
         foreach ($fields as $actor_field) {
            if (isset($input[$actor_field['name']]) && is_array($input[$actor_field['name']])) {
               $input[$actor_field['name']] = array_unique($input[$actor_field['name']]);
            }
         }

         $existing = [];
         switch ($actor_type) {
            case 'User':
               $existing = $existing_users;
               break;
            case 'Group':
               $existing = $existing_groups;
               break;
            case 'Supplier':
               $existing = $existing_suppliers;
               break;
         }
         foreach ($fields as $actor_field) {
            if (array_key_exists($actor_field['name'], $input)) {
               $existing_ids = array_column($existing[$actor_field['type']] ?? [], $actor_type::getForeignKeyField());
               $input[$actor_field['name']] = array_filter($input[$actor_field['name']] ?? [], static function ($value) use ($actor_type, $existing_ids) {
                  if (!is_array($value)) {
                     $value = [$actor_type::getForeignKeyField() => $value];
                  }
                  return !in_array($value[$actor_type::getForeignKeyField()], $existing_ids, false);
               });
            }
         }
      }                             

I tried to take a closer look at whether the code would affect something else and then simply commented out this block. I tested my actions again (mentioned above) and did not see the error anymore.

I hope this instruction will help someone. At least no more events occurred in the php-error.log file after that.

Last edited by Jem7734 (2024-08-15 15:17:41)