Enhanced ES|QL Query History incl. starring a query

[ninoslavmiskovic]

Description

We’ve introduced a feature in the ES|QL editor, where we also investigated and discussed future phases of the query history. While the current implementation allows users to track their queries, it lacks advanced features like starring and quickly recalling specific queries.

User story	Acceptance criteria
Starring a query in Query History - As a user, I want to star/favorite specific ES|QL queries from my query history for quick recall later.	Users can mark queries as “starred”, which will be easily accessible from within the query history window as a separate tab.  Starred queries should remain available even after the main query history is cleared or exceeds its limit.
500 starred queries as max - As a user, I want to view max 100 starred queries in my “Starred” section.	The “Starred” part of the query history should be expanded beyond 20 queries to max 100. Perhaps introduce pagination or lazy loading to handle large history efficiently. Users should be able to scroll through older queries or load more on demand.
Warning when I reach my limit of 100 starred queries - As a user, I want to get a warning when I reach my limit of 100 starred queries, so I can manage my queries proactively.	Users are notified when their starred query section reaches the maximum limit (e.g. 100 queries)
Sort my “Starred” queries - As a user, I want to be able to sort my “Starred” queries history based on timestamp like on query history items.	The starred queries tab should be sortable like the query history tab on timestamp.

Product Requirement Document

Wireframes

[elasticmachine]

Pinging @elastic/kibana-esql (Team:ESQL)

[stratoula]

We had a sync withj @rudolf and @Dosant asynchronously. We agreed that:

• we are going to extend the favorites service to store more information than just ids. Specifically we would like to store something like that per user id

"esql_queries": [
        {
          "queryString": "FROM logs",
          "id": "<a random id>",
          "timeRan": "<timestamp>"
        }
        {
          "queryString": "FROM logs | STATS count = COUNT(*)",
          "id": "<a random id>",
          "timeRan": "<timestamp>"
		},
      ]

• The service is going to limit the user to max 100 starred queries. We want to be sure that we are not going to cause any performance / storage problem. If there are complains from the users we can rediscuss.
• The users will be able to star / unstar queries

[azasypkin]

@stratoula, do we envision any sensitive or PII data being included in the queryString? I assume the answer is "yes, probably", but I'm not sure.

/cc @elastic/kibana-security

[stratoula]

@azasypkin these are queries that the users are authoring so I am assuming that yes. But which is the difference on what we do already? I mean now the users can write an ES|QL query and save it to a dashboard or Discover saved search. (also as these are SOs they can export and import them to other instances).

[azasypkin]

But which is the difference on what we do already?

Sure, there doesn't seem to be any difference from what we already do. I don't think there's anything to worry about here. I'm mostly asking to get a fuller picture of what user/user-generated data we store and where, especially with regard to new functionality.