You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The information in the card title for a field that is ready for the update as it has been reviewed or edited 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.
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.
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.
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"?
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.
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.
The information in the card title for a field that is ready for the update as it has been reviewed or edited 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.
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.
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.
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
The text was updated successfully, but these errors were encountered: