[APM] Custom actions: Settings list page for managing custom actions

[formgeist]

Summary

As outlined in the design elastic/apm#196 we want to enable users to create custom actions that will appear in the Actions context menus in the UI. Currently available in the Transaction detail view and detail flyouts for Transactions in the Timeline.

Settings list page for custom actions management

To allow the user to manage their custom actions, we want to add a new section to the existing APM settings view. A general view for customizing the APM UI with a section panel for managing custom actions.

Design screens for implementation

Links
Figma prototype

• Add new "Customize UI" view to the Settings pages
• Add EmptyPrompt inside the custom actions panel if there are no custom actions created yet.
• Show list of custom actions for all services
• Enable KQL search client-side keyword filter on the list of actions*
• Compressed table list of custom actions;
  • Action name
  • Action URL
  • Last updated timestamp
  • Manage actions (invoke edit flyout for editing and deleting options)
• Paginate at max 50 items

*We have cut the scope of adding KQL search to the list of actions, to simply be able to keyword search the available columns (name and URL) as a way for the user to locate a specific action. KQL filter would be nice as that would allow the user to also locate actions related to e.g. a specific service or transaction name.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[sorenlouv]

I'm a little late to the party but if possible I'd like to hear more about the use cases around using service.name and service.environment as the only context filters. I saw some chatter about having transaction.type as well. Additionally I can imagine that it would be beneficial to conditionally show links for certain type of documents, eg. errors, spans, transactions or metrics.
Lastly, what if a user wants to show a link for two or more services (but not all)?

I think it'll be difficult ui-wise, and a lot of work coding-wise to cater to all these different needs with the current approach. At the same time I think the current approach is very limiting to the point that I doubt how useful it'll be.

Did it ever come up to use kql as a filter? So instead of us handpicking a few fields, the user should be able to filter links by any of the fields in the APM docs (like in the query bar). We already have autocomplete for this, so the UX will feel pretty good. This way the user can add a link by specifying label, url and an optional filter written in kql.

I agree, this is the slightly more technical (nerdy) approach. It is not for everyone, but Elastic users should be familiar with the syntax and it'll give them the power and flexibility they expect.

[cauemarcondes]

I'm a little late to the party but if possible I'd like to hear more about the use cases around using service.name and service.environment as the only context filters. I saw some chatter about having transaction.type as well. Additionally I can imagine that it would be beneficial to conditionally show links for certain type of documents, eg. errors, spans, transactions or metrics.
Lastly, what if a user wants to show a link for two or more services (but not all)?

I think it'll be difficult ui-wise, and a lot of work coding-wise to cater to all these different needs with the current approach. At the same time I think the current approach is very limiting to the point that I doubt how useful it'll be.

Did it ever come up to use kql as a filter? So instead of us handpicking a few fields, the user should be able to filter links by any of the fields in the APM docs (like in the query bar). We already have autocomplete for this, so the UX will feel pretty good. This way the user can add a link by specifying label, url and an optional filter written in kql.

I agree, this is the slightly more technical (nerdy) approach. It is not for everyone, but Elastic users should be familiar with the syntax and it'll give them the power and flexibility they expect.

@sqren I really liked your idea, it will give a lot of freedom to our users to create theirs own filters. A question about the context fields, I thought the user could add it in the middle of the URL e.g /{service.name}/{transaction.id}, is it right?

[sorenlouv]

A question about the context fields, I thought the user could add it in the middle of the URL

Yes, but that's the template variables. These are not to be confused with the context values. I'll clarify my terminology below.

Context values
These decide where a link should be displayed. Eg. whether it should be displayed for a particular service, transaction type or maybe even a specific trace.

Template variables
These are dynamic values that can be injected into a link. Say a link is shown for all services but the link should point to the service name that corresponds to where the link is currently displayed:

www.externalsite/foo/{service.name}/data

EDIT: changed "contextual filters" to "context values" per @dgieselaar's suggestion

[dgieselaar]

@sqren FWIW, I'm using "context values" for annotations, which use a similar concept. "Contextual filters" could be confused with, you know, contextual filters.

[formgeist]

We just discussed on Zoom exploring two similar but different approaches to the creation of the custom action;

1. User can use the KQL bar to query a specific match that will display the custom action in context of their query
2. User can fill out a number of key/value pair fields like service.name, service.environment or labels.foo. This is more restricted than the KQL bar, but perhaps also makes the creation a little more user friendly by only being able to fill out specific parameters.

Common for both use cases will be additional changes and features like;

• Move label and URL to the top as the required fields. Which means the user can choose to have a custom action appear for all services and environments if they choose to do so. By default a custom action is not scoped to any specific service or environment.
• Add an option to test the custom action: Because the two approaches (especially the latter) are hard to validate in forms, we want to provide the user with an option to test their action.

I'll make some mocks that we can use to discuss which approach we prefer, and let's set up a sync tomorrow if possible in order for us to move forward with the implementation.

Thanks for your feedback and input @sqren 👍

[formgeist]

@cauemarcondes I've updated the description with a new task list and prototype link and screens. Let me know if you have any comments or feedback.