Allow classes to define client side actions

[AdrienClairembault]

Checklist before requesting a review

• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works -> no features to test yet

Description

Classes can now implement a HasClientSideActionsInterface interface like this:

#[Override]
 public function getClientSideActions(): ClientSideActionList
  {
      $list = new ClientSideActionList();
      $list->add(new ClientSideAction(
          key: "do_something",
          icon: "ti ti-send",
          label: "My action",
      ));
      return $list;
  }

In this example, this will add the "My action" entry to the single action dropdown:
Which will display this:

This action does nothing by default.
You can then listen to the event (using the value defined as the key) to execute client side code as needed:

document.addEventListener('do_something', () => {
    console.log("Doing something");
});

This will be needed for the upcoming KB rework as we need to execute some client side logic using the action dropdown.

[cconard96]

My initial reaction to this is that it does not seem ideal.
Based on what I saw for the KB rework, the usual tabbed form display will not be used so why the need to try to add client-side actions into the massive action system that wasn't designed with them in mind?

[AdrienClairembault]

the usual tabbed form display will not be used

I am going for a progressive improvement approach here, with the goal to improve the KB step by step without breaking everything.

The target for the first iteration is simply to start removing tabs one by one (by moving the content into the main tab and the "actions" dropdown).

We don't need a custom layout for that, we'll work on it in another iteration.

the massive action system that wasn't designed with them in mind

Doesn't seem a big issue to me, there are 10 lines added in the backend code and 5 on the client.
If anything, it seems to be an easy addition that could be reused for other features if needed.

[AdrienClairembault]

(My bad it should target main tho).

[cconard96]

Doesn't seem a big issue to me, there are 10 lines added in the backend code and 5 on the client. If anything, it seems to be an easy addition that could be reused for other features if needed.

How does this affect the use of massive actions in the legacy API?
Are these client-side actions ignored when not in a single-item context?

The new KB looks like an interactive client-side feature, but this code doesn't seem to align with that. Granted, this is indeed only a very small part of the work so I don't have the full view of where this is going.

[cconard96]

My opinion that is probably not surprising to anyone, is to implement the main view (including an actions toolbar) of the KB in Vue to start and then slowly replace the tabs with features in that view. Otherwise, you are looking at potentially building this feature as SSR just to rewrite it again later.

[AdrienClairembault]

My opinion that is probably not surprising to anyone, is to implement the main view (including an actions toolbar) of the KB in Vue

I don't want to start adding Vue code until it's been agreed by most of the team (there are still a lot of people strongly against it).
There is still much to be discussed on this side and I don't want to go in this direction until there is a clear view of what we want the future of GLPI to look like.

While this feature require some client interactions, the vast majority of it are very simple tasks like toggling some item visibility (side panel, modals, alerts, ...) and enabling/disabling the rich text editor.

I think a standard JS module will be plenty enough for this (maybe time will prove me wrong, but that's how I see it when trying the mock I was given).

[AdrienClairembault]

How does this affect the use of massive actions in the legacy API?
Are these client-side actions ignored when not in a single-item context?

This is only for single items. API should already be excluded but I'll add another check to be safe.