New artifacts schema in the rule creation/update/find

[mgiota]

Fixes #219523

🗒️ Summary

We want to add a new root-level key in the rule called artifacts. The new key will be added to the create, update and find Rule apis and will contain dashboards and investigation_guide. This PR handles only the addition of dashboards.

artifacts: {
    dasboards: Array<{ id: string }]>;
}

Architecture diagram

🧪 How to test

This PR includes only backend changes to the Rule APIs. In order to test you can use Kibana > Dev Tools.

Create a rule

POST kbn:/api/alerting/rule
{
  "name": "TEST RULE",
  "params": {
    "criteria": [
      {
        "comparator": ">",
        "metrics": [
          {
            "name": "A",
            "aggType": "count"
          }
        ],
        "threshold": [
          3
        ],
        "timeSize": 1,
        "timeUnit": "m"
      }
    ],
    "alertOnNoData": false,
    "alertOnGroupDisappear": false,
    "searchConfiguration": {
      "query": {
        "query": "",
        "language": "kuery"
      },
      "index": "e7744dbe-a7a4-457b-83aa-539e9c88764c"
    }
  },
  "rule_type_id": "observability.rules.custom_threshold",
  "consumer": "logs",
  "schedule": {
    "interval": "1m"
  },
  "artifacts": {
    "dashboards": [
      { "id":"1" }
    ]
  }
}

The artifacts shouldn't be returned in the rule response. The new dashboard artifacts should be saved in the Rules SO. You can check it directly under Kibana > Stack Management > Saved Objects. You should verify a new artifacts entry is added in the rules SO:

"artifacts": {
      "dashboards": [
        {
          "refId": "dashboard_0"
        }
      ]
    },

Also the new dashboard should be added into the references array:

"references": [
    ..
    {
      "id": "1",
      "name": "dashboard_0",
      "type": "dashboard"
    }
  ],

Update a rule

PUT kbn:/api/alerting/rule/{RULE_ID}
{
  "name": "TEST RULE",
  "schedule": {
    "interval": "1m"
  },
  "params": {
    "criteria": [
      {
        "comparator": ">",
        "metrics": [
          {
            "name": "A",
            "aggType": "count"
          }
        ],
        "threshold": [
          3
        ],
        "timeSize": 1,
        "timeUnit": "m"
      }
    ],
    "alertOnNoData": false,
    "alertOnGroupDisappear": false,
    "searchConfiguration": {
      "query": {
        "query": "",
        "language": "kuery"
      },
      "index": "e7744dbe-a7a4-457b-83aa-539e9c88764c"
    }
  },
  "artifacts": {
    "dashboards": [{"id": "2"}, {"id": "1"}]
  }
}

The artifacts shouldn't be returned in the rule response. The updated artifacts should be saved in the Rules SO. You can check it directly under Kibana > Stack Management > Saved Objects. You should verify the updated dashboards list is correct.

Find a rule

GET kbn:/api/alerting/rules/_find?search="TEST RULE"

The artifacts shouldn't be returned in the rule response. Only the internal Find API returns the artifacts.

POST kbn:/internal/alerting/rules/_find
{
  "search": "TEST RULE"
}

✔️ Acceptance criteria

• The dashboard IDs should be saved as `references in the Rule SO
• The Rule APIs will not return the artifacts
• Only the internal Find API used by the UI will return the artifacts
• Integrations and unit tests should be added

[mgiota]

Same schema is defined in server/application/rule/schemas/rule_schemas . Is there any reason why we have the schemas duplicated in these two files? I checked existing schemas and they are duplicated in these 2 files, x-pack/platform/plugins/shared/alerting/common/routes/rule/response/schemas/v1.ts and x-pack/platform/plugins/shared/alerting/server/application/rule/schemas/rule_schemas.ts

Can I reuse the schemas from common folder?

[cnasikas]

The schemas in the common/routes folder are for the routes, and the schemas in server/application/ are for the rule client. Even if they are the same, they may diverge in the future. Routes can evolve differently from the rule client to avoid breaking changes, for example. I would say not to use common/routes schemas in the rule client and duplicate the types as you did.

[mgiota]

@elasticmachine merge upstream

[mgiota]

@elasticmachine merge upstream

[kibanamachine]

Starting backport for target branches: 8.19

https://github.com/elastic/kibana/actions/runs/14612794479

[kibanamachine]

💔 All backports failed

Status	Branch	Result
❌	8.19	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 216292

Questions ?

Please refer to the Backport tool documentation

[mgiota]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation