-
Notifications
You must be signed in to change notification settings - Fork 9
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
Alert description parsing #654
Conversation
$output->usesParsedDescription = false; | ||
} else { | ||
$output->description = $alertDescription; | ||
$output->usesParsedDescription = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no good way in a twig template to determine if some attribute on an object in question is or is not an array. Here the alert.description
field will be an array with named keys. Otherwise it's just the description string itself. We use this boolean field in the twig template to determine how we display the field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't pulled this down and run it locally yet, but the code looks good!
Code Review Checklist
A checked item is either an assertion that I have tested this item or an indication that I have verified it does not apply to this pull request.
The Basics
- Checks are passing
- I read the code
- I ran the code
Documentation
- changes to “how we do things” are documented in READMEs
- all new functions and methods are commented using plain language
- any new modules added documented in modules.md
Security
- security false positives are documented
- data from external sources is cleaned and clearly marked
Reliability
- error handling exists for unusual or missing values
- interactions with external systems are wrapped in try/except
- functionality is tested with unit or integration tests
- dependency updates in composer.json also got changed in composer-lock.json
Infrastructure
- all changes are auditable and documented via a script
- it is clear who can and should run the script
- (if applicable) diagrams have been updated or added in PlantUML
Accessibility
- New pages have been added to cypress-axe file so that they will be tested with our automated accessibility testing
- Meets WCAG 2.0 AA or 2.1 AA for Section 508 compliance
- Site is keyboard accessible. All interactions can be accessed with a keyboard
- Site is free of keyboard traps. The keyboard focus is never trapped in a loop
- All form inputs have explicit labels
- Form instructions are associated with inputs
- All relevant images use an img tag
- All images have appropriate alt attributes
- Multimedia is tagged. All multimedia has appropriate captioning and audio description
- Text has sufficient color contrast. All text has a contrast ratio of 4.5:1 with the background
- Site never loses focus. Focus is always visible when moving through the page with the keyboard
- Tab order is logical
- Tables are coded properly. Tables have proper headers and column attributes
- Headings are nested properly. Heading elements are nested in a logical way
- Language is set. The language for the page is set
- CSS is not required to use the page. The page makes sense with or without CSS
- Links are unique and contextual. All links can be understood taken alone, e.g., ‘Read more - about 508’
- Page titles are descriptive
Device Matrix
- firefox/gecko (renders correctly and user interactions work)
- chrome/chromium/edge (renders correctly and user interactions work)
- safari/webkit (renders correctly and user interactions work)
- web page is readable and usable
- at 480px (mobile)
- at 640px (tablet)
- at 1024px (desktop)
Co-authored-by: Greg Walker <[email protected]>
What does this PR do? 🛠️
Per #589, this PR implements basic Alert
description
field parsing, along with basic integration into the alert template.What does the reviewer need to know? 🤔
The parsing is regex based. It will look for any word in all caps followed by ellipses, and use that as the label. This means we don't specifically search for WHAT/WHEN/WHERE/IMPACTS tokens. If we want to be more literal to the observed format, and more strict, we can switch over.
When the regex matches successfully, the
description
field on the processed alert object will become an associative array whose keys are the labels in lowercase ("what" "where" etc) and whose values are the text content for that label.When the regex fails to match, the plain description string is displayed, with the white space adjusted.
Screenshots (if appropriate): 📸
Before:
After: