Fixes #24363: Display compliance for system groups

[clarktsiory]

https://issues.rudder.io/issues/24363

We need to support either a groupId (e.g. an uuid) or a target (e.g. special:... or even group:...).

Common fields that we need for the compliance result are id, name, serverList, the code is refactored accordingly.

Screenshots :

This one needs some change in the UI (in another PR) :

[clarktsiory]

PR updated with a new commit

[clarktsiory]

PR updated with a new commit

[fanf]

why not using the serialisation of node group as a SimpleTarget ? That datastructure is here just for that (ie abstracting over the different kind of targets: groups, system ones, etc).
You will get a string lile: group:90994f11-1638-4945-add0-70dc543e80d0 or special:all or policyServer:root etc.

And then just always parse back a SimpleTarget, and fail - ie parseSimpleTargetOrNodeGroupId does not seems necessary and inconsistent with the general way of representing rule targets.

[clarktsiory]

It is indeed clearer to directly use it within the API.
As a consequence, the Elm app will need to reason over both target and group ids, because it parses and uses the raw group uuid as returned in the group tree. The change is here : 5c521e4

And I am not sure if parseSimpleTargetOrNodeGroupId should actually be removed, we have an API endpoint that looks like api/compliance/groups/9362944f-781d-4d9c-b8af-bfcdee8e63bb now, and we should assume this is the basic "Public API" interface, but also allow for the api/compliance/groups/group:9362944f-781d-4d9c-b8af-bfcdee8e63bb.
I don't think we want to return "not found" with : api/compliance/groups/9362944f-781d-4d9c-b8af-bfcdee8e63bb.

[fanf]

Ah, yes. It's a public API used internally.
OK, if it's not only a private API, api/compliance/groups/group:9362944f-781d-4d9c-b8af-bfcdee8e63bb doesn't make much sense for an user, esp since we don't have that anywhere in the public API (plus the fact it's "group" and not "target" in the url).

Could it be api/compliance/targets/group:... - it would at least bring some consistency. Perhaps we need to ask other.

[VinceMacBuche]

I do think it should accept both values: a node group id directly and a target (including group:nodeid) and it should be an either Here. or above you can translate something that does not match a target to a groupTarget

[clarktsiory]

Indeed that's exactly what the parse function does and always ends up with a target :

private[this] def parseSimpleTargetOrNodeGroupId(str: String): PureResult[SimpleTarget] = {
    // attempt to parse a "target" first because format is more specific
    RuleTarget.unserOne(str) match {
      case None        => NodeGroupId.parse(str).map(GroupTarget(_)).left.map(Inconsistency(_))
      case Some(value) => Right(value)
    }
  }

[VinceMacBuche]

I think you should answer with the id and not the target in json response

[clarktsiory]

Then I should just revert the whole commit that replaced everything with a target : 5c521e4 ?

[fanf]

OK, so this kind of subject gives more whatever to the idea that elm application should only use internal, RPC like APIs, and that public API have a different set of goals and contracts.

In that example, the correct, simple RPC like thing that the elm app need is in contradiction with what user expects : elm does care about writting .../group:9362944f-781d-4d9c-b8af-bfcdee8e63b, but it's very weird for an human.

Since that API is a public one, yes we need to support the scheme and convention we use elsewhere, so:

• .../groups/9362944f-781d-4d9c-b8af-bfcdee8e63b needs to be supported for human convenience in the scala API,
• .../groups/special:all needs to be supported because the model is like that.

And so, even if the elm app always use the correct, full serialisation of target, the backend needs to have a parser like the one you had initially.

Sorry to have missed the fact that the API was public and set you on a bad path.

[clarktsiory]

Okay, it is not an issue, I didn't emphasis on the API being public either...

So I am reverting the change, and for the details, Elm also doesn't always make requests with group:... but directly with the UUID because it receives the UUID from the "group tree"

[fanf]

There is a CSS problem when there is a lot of nodes:

Please open an other ticket to correct it indepently from that one (ie it doesn't already exist).

[fanf]

Appart for the serialization subject, it seems to work as expected. Once corrected, you will be able to just add the "ready for merge" tag. Plus need to open an other ticket for the css problem when there is a lot of nodes.

[clarktsiory]

PR rebased

[clarktsiory]

PR updated with a new commit

[Normation-Quality-Assistant]

OK, merging this PR