Improve log search with multi-term and exclusion support

[limad]

Titre : Refactor search functionality to support multiple terms and :not filter.

Description

The log filter input (in_searchLogFilter) previously supported only a single search term at a time, requiring users to retype their query to switch between logs.

This refactor allows multiple comma-separated terms to be entered simultaneously (e.g. ai_assistant,jee_mcp), so several logs can be highlighted at once. The existing :not() syntax is preserved and now works per-term, meaning it can be mixed with positive terms in the same query.

No changes to the PHP side or the rest of the JS page were required.

Suggested changelog entry

Log filter now supports multiple comma-separated terms and per-term :not() exclusion.

Related issues/external references

Fixes #

Types of changes

• Bug fix
• New feature (non-breaking change which adds functionality)
• Breaking change
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the contribution guidelines.
• I grant the project the right to include and distribute the code under the GNU.
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added MD documentation for the sniff.

[Mips2648]

Hello,
Thanks for re-submitting this PR

I've few questions:

• Why use coma for term separation? I feel it is more common and intuitive to use a space
• why using var and not let ?

[limad]

Hello

• Why use coma for term separation? I feel it is more common and intuitive to use a space
  Peu importe.
• why using var and not let ?
  pour éviter des problèmes JS connues sur le fronted Jeedom "...already declared", le code d'origine est aussi en "var"

[Mips2648]

Peu importe

non, pas "peu importe": le but ce n'est pas de faire n'importe quoi, n'importe comment donc c'est important de réfléchir à tous les aspects: qualité du code, pertinence de l'idée, UX, facilité d'utilisation etc...

et par rapport au var vs let;
c'est une mauvaise pratique d'utiliser var, le défaut en JS actuellement est d'utiliser des const si possible ou let lorsqu'on doit modifier mais pour que dans les 2 cas le scope soit limité et sous controle.
si une autre var existe dans le dom, c'est juste écrasé car variable globale...

ici on est dans une fonction et c'est clair que son but n'est pas de ré-utiliser des variables globales, donc la réponse "pour éviter des problèmes already declared" est injustifiée.
Ce n'est pas parce que c'était comme ca qu'on ne peut pas améliorer la situation progressivement...

---

Nouveau et dernier point pour l'instant:
pourquoi juste gérer ce champ de recherche? si on veut garder une cohérence et que les utilisateurs s'y retrouvent, la feature "multi-terms search" devrait exister ailleurs aussi probablement;
il faut au moins se poser la question

[limad]

non, pas "peu importe": le but ce n'est pas de faire n'importe quoi, n'importe comment donc c'est important de réfléchir à tous les aspects: qualité du code, pertinence de l'idée, UX, facilité d'utilisation etc...

J'avais mis "virgule" car cela me paraissait cohérent et plus rationnel d'avoir un caractère qu'on ne peut pas rencontrer couramment. Si d'autres personnes jugent qu'un espace est mieux pour les logs, pourquoi pas, du moment qu'on a la fonctionnalité.

par rapport au var vs let; c'est une mauvaise pratique d'utiliser var, le défaut en JS actuellement est d'utiliser des const si possible ou let ...

Ma PR est une "New feature (non-breaking change which adds functionality)" et non une "code review".
Il serait plus cohérent de traiter les questions de let/var/const dans des PR spécifiques et pour l'ensemble des JS du core.

Nouveau et dernier point pour l'instant: pourquoi juste gérer ce champ de recherche? si on veut garder une cohérence et que les utilisateurs s'y retrouvent, la feature "multi-terms search" devrait exister ailleurs aussi probablement; il faut au moins se poser la question

Certainement, j'ai fait la PR pour les logs (que j'utilise souvent), mais ce besoin peut concerner d'autres pages.

Plus globalement, je ne sais pas s'il existe des règles pour soumettre des PR sur le Core, mais il serait bien d'en établir quelques-unes, pour que chacun ne perde pas son temps.