Design a request management system for Console requests

cjcenizal commented 2 years ago

The problem

The Console requests pane doesn't scale well.

As the user enters more and more requests, the request pane grows taller and taller. Once it gets tall enough, it becomes difficult to find a specific request among the others. Because there's no grouping mechanism the user has to write comments to demarcate and label "sections" in the request pane. These are also difficult to locate and discern from one another when there are many.

References

There are related issues that hint at the need for improved request-management tools:

Requirements

CRUD. Assuming that our system of managing requests will consist of grouping them into "files", then the user must be able to easily create, view, edit, and delete files. The user will need to be able to name files and will need to be warned of collisions. When there are many files, this will necessitate tools such as bulk actions (such as bulk delete), sorting, filtering, and searching.

Scratch pad. The user should be able to use it as it's currently used today, without needing to create a new file. From the moment Console is first opened, the user should immediately be able to write, run, edit, and delete requests. This can be supported by providing a default "scratch pad" file, that can't be deleted.

Load_from must work. The load_from parameter is currently used to support loading requests via deep-link, e.g. through the "View in Console" link in our documentation, the "View request" flyout (https://github.com/elastic/kibana/pull/127156), or the request inspector (https://github.com/elastic/kibana/pull/109923). This must continue to behave as before. I suggest it should populate the scratch pad.

Nice-to-haves

Folders and/or labels. Being able to group files in folders or by labeling them can help folks keep their files organized when there are many of them, similar to Postman functionality.

Metadata. Information such as date edited, date viewed, and date created can help users recall which files they've been using most recently, and identify obsolete ones that can be deleted. Information such as who owns a file and who has access to it is also useful, but only once sharing features have been added.

Shareability. Once we have a model for defining ownership of saved objects, we can store file information in a saved object and share files with users and spaces.

Export and import. Per https://github.com/elastic/kibana/issues/29999, this can help administrators move saved requests between clusters.

Prior art

This functionality was first implemented and abandoned by a community member for 6.x in 2018 (https://github.com/elastic/kibana/pull/17091).

In 2020, @jloleysens built out this functionality for 7.x (https://github.com/elastic/kibana/pull/57310).

I also iterated on JL's work and explored an alternative direction (https://github.com/jloleysens/kibana/pull/1).

elasticmachine commented 2 years ago

Pinging @elastic/platform-deployment-management (Team:Deployment Management)

elasticmachine commented 1 month ago

Pinging @elastic/kibana-management (Team:Kibana Management)

elastic / kibana