[Request] Prebuilt rule customization, upgrade, and export/import workflows - UI copy review

[ARWNightingale]

Epic: elastic/kibana#174168
Related to: #5061
PR: elastic/kibana#210817

Summary

Description

We are introducing the ability for users to customize prebuilt Elastic rules and adjusting the rule upgrade workflow to adapt to that change. This includes ability to:

• edit and customize prebuilt rules (modify almost all rule parameters, besides rule actions);
• export and import prebuilt rules, including customized ones;
• upgrade prebuilt rules while keeping the user customizations whenever possible.

More information in the main docs ticket: #5061.

Related links / assets

• Figma design
• Github epic

Collaborators

• PM: @approksiu
• Designer: @ARWNightingale
• Engineers: @banderror @xcrzx @maximpn @nikitaindik @dplumlee

Please reach out via the team channel.

UI copies

Prebuilt rule customization workflow

• Tooltips for the Author and License fields. Displayed on the Rule Editing page.

• "Modified Elastic rule" badge. Displayed on the Rule Details page, Rule Management page - Installed Rules table, and Rule Management page - Rule Updates table.

• "Modifications" filter. Displayed on the Rule Management page - Rule Updates table.

Prebuilt rule upgrade workflow - Rule Updates table

• Tooltips about rules having conflicts.

• Modal about rules having conflicts.

Prebuilt rule upgrade workflow - Rule Upgrade flyout

• Flyout header and footer.

• Updates tab: title and status bar.

• Updates tab: overall update status callouts.

• Rule field view: update status indicators.

Field has an update from Elastic, but it hasn't been customized by the user:

Field has been customized by the user, but there's no update from Elastic:

Field has been customized by the user AND it has an update from Elastic. The app was able to auto-merge these changes and suggest a final field value to upgrade to. This represents a potential conflict. The user has to review the conflict between their changes and the update from Elastic, review the "final update" value and either accept the suggested value or edit it before accepting:

Field has been customized by the user AND it has an update from Elastic. The app was NOT able to auto-merge these changes and suggest a final field value to upgrade to. This represents a conflict. The user has to review the conflict between their changes and the update from Elastic, edit the field value and resolve the conflict manually:

Conflict has been resolved by the user:

"Modified" badge and its tooltips:

• Rule field view: diff view and diff selector.

@pborgonovi had a concern about explanation wording for "My changes" in this tooltip. Please take a look and feel free to suggest an improvement.

• Rule field view: final update view, readonly mode.

• Rule field view: final update view, editing mode.

• Edge case: rule type change.

If it's a stock, non-customized prebuilt rule:

If it's a customized prebuilt rule:

Licensing restrictions

TBD. Details will be added by @xcrzx.

[nastasha-solomon]

Hey @ARWNightingale - some suggestions and a couple of questions about the field statuses and requested user actions:

The information in the card title is for a field that is ready for the update as it has been reviewed or edited and accepted.

• You can remove the period at the end since this is not a complete sentence.
• Is there a reason why “Reviewed and accepted” isn’t followed by additional information like the other statuses? For example, I would expect to see something like:
• Reviewed and accepted - The changes have been reviewed and accepted.

The information in the card title for a field that is ready for the update as there were no conflicts as the final update and all looks good.

• What actions would a user have taken to get to this point? I’m a little confused with the sentence “The update has no conflicts and has been applied to the final update” because I don’t understand how a field can be ready for an update if the update has already been applied to the final update (which seems to be the final version of the field).

The information in the card title for a field that needs to be reviewed as we have tried to solved a conflict in the merging of the current and elastic update.

• In this case, resolved is slightly more correct than solved. When you resolve something, you fix an issue or settle a dispute. When you solve something, you find the correct answer to a problem. (If you make this change, I also recommend applying it wherever "unsolved" is used in the UI copy for this feature.)
• The explanation can be shortened and I recommend removing "please” as we usually avoid it in copy Here’s a potential revision:
  Resolved conflict - Before accepting this change, review the suggested update.

The information in the card title for a field that needs a user to input the final update as the conflict is unsolvable by Elastic then its needs to be accepted.

• If you change solved to resolved, I recommend changing unsolved to unresolved here and anywhere else where unsolved is used for this feature.
• What’s a "merge version" and how is it related to the update that the user needs to, or chooses to, accept?
• In the second sentence, what is the "current version"?

[ARWNightingale]

Hey @nastasha-solomon, I think we need to change the naming of the "Overview" tab in the update flyout. I think this can be confusing to what overview we are showing(update or existing rule). I would suggest something like "Update overview".

[nastasha-solomon]

Notes on copy review are in https://docs.google.com/document/d/1Yl6DyN9pertqgB-iIKIEN3xdvlDM50oscJ00G-WwtyA/edit?usp=sharing.

[banderror]

@nastasha-solomon Reviewed the google doc and left a few minor suggestions and nit comments. Those are some awesome corrections! Thank you.

[banderror]

@approksiu I think we don't need a separate ticket for implementing the corrections, we could use this one and assign an engineer from the team. We would just need to make it clear in the google doc what needs to be done (it's already 99% clear).

[ARWNightingale]

Hey @banderror we also wondered if we could make some adjustments to the:

1. Filter for modified/Unmodified updates in the update table, see image.
2. Change the colour of the modified filed (no update) section from green to default.

[banderror]

@ARWNightingale

Filter for modified/Unmodified updates in the update table, see image.

Yes, but I don't think it should be a blocker for the first release. Please find my comment in the doc: "Can we start with renaming it to "Modified/Unmodified" and then rewrite to the two buttons after the first release?".

Change the colour of the modified filed (no update) section from green to default.

Yep, sounds good 👍

[banderror]

@nastasha-solomon @xcrzx

Have UI copies for licensing been reviewed in elastic/kibana#206079?

[nastasha-solomon]

@banderror if the licensing copy is ready, I can take a look today.

[xcrzx]

@nastasha-solomon, could you please check these new UI elements?

• On the rule editing page, added a hover tooltip explaining why the tabs are disabled:

  • For ECH: "Upgrade to Enterprise to enable prebuilt rule customization."
  • For Serverless: "Upgrade to Security Complete to enable prebuilt rule customization."
    

• Added a bulk action confirmation dialog with the following message when rule editing is disabled due to an insufficient license:
  

• For previously customized rules, where customization is now disabled due to an insufficient license, a notification will appear on the upgrade flyout, clarifying that only an upgrade to Elastic's version is available.
  

Let me know if anything needs adjustment!

[nastasha-solomon]

@xcrzx I left some suggestions for you here. Feel free to ping me if you'd like to discuss anything further. : )

[banderror]

@nastasha-solomon @ARWNightingale @approksiu @xcrzx

If there are no other comments, we can take this into work and implement the copy improvements next week.

[nastasha-solomon]

@banderror one more thing - I was reviewing the doc issue again and noticed an ask to check the wording for disabling the building block property. As I mentioned in my reply, the text looks good but the quotes aren't needed.

[nastasha-solomon]

Copy changes were added in elastic/kibana#210817