PROBLEME ON CREATING AND UPGRADE

[JCHELIX]

Here's what we have done:

========== Creation One filter with match string /.?(?(RITM|INC)[0-9]{7,7})./ and resolve string /.?(?RESOLU)./ Active : yes
Ticket matched string 11 Solved matched groupe length : 6

The we create à Ticket witch subject RITM0000999 ==> we have then a white page ....

is we de activate and create the ticket manualy and reactivite the plugin to then try do have à Follow Up created ==> same white page ...

Any idea ?

[DonutsNL]

Hi @JCHELIX ,

Make sure the matchgroup is in the pattern.

?<match> So it should look something like this: .*?(?<match>?(RITM|INC)[0-9]{7,7})).*/ The same is treu for the solve matchpattern. Make sure the ?<solved> matchgroup is present. /.*?(?<solved>RESOLU).*/

I will check if this issue isnt handled correctly (resulting in a blank page).

rgrds,

[JCHELIX]

Many thanks for fast awnser

/.?(??(RITM|INC)[0-9]{7,7}))./ /.?(?RESOLU)./ are set . still have white page after trying to creat à ticket with RITM0000999 in sujet (existing tikect with same number already in base.

It doeasn't add any follwup to existing ticket

[JCHELIX]

[DonutsNL]

Hi @JCHELIX

Sorry for that. The < > tags are stripped in the followup. Indeed as shown in your image, the (?< ... >MATCHSTR) should be present.

Please review the GLPI_HOME/files/_log/php-errors.log for any errors originating from the plugin and share them if possible. I will try to replay your issue in my local environment this evening and see if I can cause an error with your shared configuration.

Also be aware that the minimal length is now 7 characters. That might not be the case if the pattern starts with INC and the missing chars are not padded with nummeric chars. Best change the {7,7} to {6,7} to account for the INC pattern

[JCHELIX]

Here's what i get: existing ticket :

[JCHELIX]

[2023-11-09 13:31:42] glpiphplog.CRITICAL: *** Uncaught Exception ParseError: syntax error, unexpected '|', expecting ';' or '{' in /glpi/marketplace/ticketfilter/src/Filter.php at line 179 Backtrace : vendor/composer/ClassLoader.php:428 Composer\Autoload\includeFile() : Composer\Autoload\ClassLoader->loadClass() : spl_autoload_call() src/Plugin.php:1616 is_callable() src/CommonDBTM.php:1269 Plugin::doHook() front/ticket.form.php:74 CommonDBTM->add()

[JCHELIX]

[2023-11-09 11:51:11] glpiphplog.CRITICAL: *** Uncaught Exception ParseError: syntax error, unexpected '|', expecting ';' or '{' in /glpi/marketplace/ticketfilter/src/Filter.php at line 179 Backtrace : vendor/composer/ClassLoader.php:428 Composer\Autoload\includeFile() : Composer\Autoload\ClassLoader->loadClass() : spl_autoload_call() src/Plugin.php:1616 is_callable() src/CommonDBTM.php:1269 Plugin::doHook() src/MailCollector.php:877 CommonDBTM->add() src/MailCollector.php:1894 MailCollector->collect() src/CronTask.php:1018 MailCollector::cronMailgate() front/cron.php:83 CronTask::launch()

[JCHELIX]

My partner suspect that it's our version of PHP 7.2 that need's to get upgraded to 8

[DonutsNL]

I quickly reviewed the code. If you use PHP7 im quite sure the union types used are problematic. As a workaround you might want to remove the union types manually. Simply open the file, remove the return type declaration and save the file. You might come across simular issues after you resolve this one. Simply remove all the return types that are not accepted and the plugin should work as intended but will be more susceptibel for typing related issues because i assume these types to be enforced and am not checking them again within the methods themselfs.

I marked the part that you need to remove. Its not a huge risk, but i would advice to upgrade your PHP version.

[JCHELIX]

Many thank's for all you anwser . if we get this to work like we want we will have realy a great use of you plugin has it will help us to sync Followup comming from a service Now solution.

More of : what is the use of "From source" and how to use it ?

[DonutsNL]

Is being implemented in the next version (currently available if you download directly from the repository). You might actually help me get some feedback on its workings if you would like to help me as well ;-).

Its a solution for the problem described in this issue: https://github.com/DonutsNL/ticketfilter/issues/4.

This person is actually matching asset IDs and not identifiers that are unique. The source option allows them to also match the senders to the requesters in the ticket. In other words, if you have 2 unique requesters that reference the same identifier, their updates will only be added to the ticket actually generated by them.

The latest version of the codebase should be considered beta. But i would realy be helped with some feedback on its implementation and usability.

[DonutsNL]

Hi @JCHELIX

Please let me know if the hack worked for you so I can close the ticket.

Rgrds,

[JCHELIX]

hi there this worked fine. Looking forward no to use the source Field ==> what kind of source can we mention ? a specific email ?

[JCHELIX]

closing this ticket ==> if you can help me on source field .

[DonutsNL]

The field becomes a toggle (yes/no). Enabling it will only update tickets in which the sender (mail from header) is present in the found tickets requester field.

[DonutsNL]

@JCHELIX i created a pre-release with the new feature. If you are able to test it for me and provide me with feedback i am most greatfull :)

https://github.com/DonutsNL/ticketfilter/releases