-
Notifications
You must be signed in to change notification settings - Fork 2
Redesign look and behavior of recommended actions #532
Comments
|
Correct.
This is something we need manually do for now. Take a stab at it and I'll correct.
That's an edge case. That one shouldn't have this action. |
Hmm @a-martynovich the readability with white on yellow is not ideal. Can you do black text just to get me a sense for how that looks? |
@vpetersson On the previous screenshot the severity label was also half-opaque, turning fully opaque on hover (because it's supposed to be a "close" button like an "x"). I made it fully opaque now. |
@vpetersson Here's the dropdown: |
@a-martynovich Thanks. Are we able to override these colors to the default ones from Bootstrap? |
@vpetersson Not without breaking the layout elsewhere. So if we're going to fallback to Bootstrap we might as well need to do it globally as much as possible. |
Ok noted - I'm not a big fan of the current color scheme but let's leave that aside for now then. |
Just one service? Or multiple services? And to which recommended actions from the list I gave you is it applicable? |
I think we need to redesign this to a per-service basis. If not, it makes it very difficult when you have N nodes involved. |
@vpetersson this doesn't answer the question. |
Ok, fair. I've spent a fair bit of time thinking about the issues in the current design, and I think i need share some backstory for this to make sense. Currently any Recommended Action (RA) can have X nodes and Y sub-actions (e.g. multiple vulnerable services, or configuration changes). What I'm saying is that I think we need to change this structure, such that a recommended action can only have X nodes, but each sub-action would be its own recommended action. So what this means in practical terms is as follows:
(Do note that I want to completely refactor the RAs for CVEs) So cross-references to the the list in WoTTsecurity/wott-io#198, we should with this change now have a 1:1 mapping between an event and N nodes. Does that make sense? |
@vpetersson No, how does this apply to this particular task? I'm not asking about future developments, I'm asking about the current state of things. Given how we currently generate recommended actions what is "the affected service (e.g rsh-server) if applicable" which you want to track? And to which recommended actions is this applicable? |
I see what you mean now. Leave that particular Mixpanel event out now due to the issue I outlined above. |
@a-martynovich Here's the categorization
|
Because currently we have 1 recommended action for insecure services and 1 action for OpenSSH I've set their severity to High. Later we can refactor this, of course. |
Sure, that's fine. |
@vpetersson You've been asking how do recommended actions look in vanilla Bootstrap. Here's my attempt: |
Interesting. So some things are better and some things are worse. Would it be possible to only override (or rather, use vanilla bootstrap) on the buttons and the severity badge? |
That's much better! I'm OK with this blue shade for now. |
@vpetersson This concerns me a little bit. Notice the new color of those buttons: Either I got too used to the current color scheme or my eyes deceive me, but it looks like a cyan button fits this color scheme better than a blue one. None of them fit perfectly, though. |
We need to redesign the recommended actions feature a bit to make it more intuitive.
Here's a quick mock-up:
The changes are as follows:
<span class="badge badge-danger">Severity: High</span>
<span class="badge badge-warning">Severity: Medium</span>
<span class="badge badge-secondary">Severity: Low</span>
btn-success
and a Mixpanel event.btn-danger
and send Mixpanel event.btn-secondary
and Buttons-with-dropdowns.Mixpanel events
The mixpanel events should include the following meta data:
fired that includes the button and what recommended action it was as meta data.
The text was updated successfully, but these errors were encountered: