Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule updating enhancements - 8.18 Release #6238

Open
ARWNightingale opened this issue Nov 25, 2024 · 1 comment
Open

Rule updating enhancements - 8.18 Release #6238

ARWNightingale opened this issue Nov 25, 2024 · 1 comment
Assignees
Labels

Comments

@ARWNightingale
Copy link

ARWNightingale commented Nov 25, 2024

Description

For the upcoming and ongoing work on rules update we need some UI copy for 2 parts of the flow.

Dropdown diff view

. can we come up with some better more user centric copy for the dropdown to describe the options the user can view the diff.
The options we want to become more understandble are:
Base = is security-rule Saved Object (rule asset) user used to install a prebuilt rule.
Current = An installed prebuilt rule is current.
Target = And target is a new version of rule asset users get from a new package version.
Image

Update field and overall status

I have made these suggestions to better describe the status and action required for each option that can occur. I think we just needed to be clearer that an action, Review and accept, input required, update rule is explained better. this figma file has the updates I am suggesting.

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

  2. 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.
    Image

  3. 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.
    Image

  4. 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.
    Image

https://www.figma.com/design/gLHm8LpTtSkAUQHrkG3RHU/%5B8.7%5D-%5BRules%5D-Rule-Immutability%2FCustomization?node-id=5568-127385&t=GJKrhTR6MyBPsAza-1

Related links / assets

Figma link: Design

Github epic link(s): https://github.com/elastic/security-team/issues/11224

Which documentation set does this change impact?

ESS and serverless

Feature differences

NA

Software version

8.18

Collaborators

PM: Kseniia Ignatovych
Designer: Alex Nightingale
Developer: Georgii Gorbachev

Timeline / deliverables

We need this by 15th December 2024

@nastasha-solomon
Copy link
Contributor

nastasha-solomon commented Dec 3, 2024

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"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

No branches or pull requests

2 participants