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

feat: Aggregating Alerts Feature #2230

Merged
merged 4 commits into from
Feb 29, 2024

Conversation

jdslaugh
Copy link
Contributor

@jdslaugh jdslaugh commented Feb 12, 2024

Description

Aggregates alert notices that are passed into the AlertList component and then parses them in the DefinitionList.

Motivation and Context

The UI is cluttered when there are numerous alerts taking up space, especially when many of them have the same title. Aggregating them into one modal alleviates this and reduces the visual strain on the user.

Screenshots (Before)

Notices

Screenshot 2024-02-09 at 3 20 46 PM

Modal

Screenshot 2024-02-09 at 3 20 51 PM

Info SVG Icon Alignment

Screenshot 2024-02-23 at 12 51 57 PM

Screenshots (After)

Notices

Screenshot 2024-02-23 at 12 56 24 PM

Modal

Screenshot 2024-02-09 at 3 18 18 PM

Storybook

Screenshot 2024-02-09 at 3 41 36 PM

Info SVG Icon Alignment

Screenshot 2024-02-23 at 12 56 24 PM

How Has This Been Tested?

  • Utilizing mock data to recreate the notices that can be aggregated as well as without aggregation.
  • Unit testing through already existing tests in place
  • Verification and updates to storybook and related components

CheckList

  • PR title addresses the issue accurately and concisely
  • Updates Documentation and Docstrings
  • Adds tests
  • Adds instrumentation (logs, or UI events)

Copy link

boring-cyborg bot commented Feb 12, 2024

Congratulations on your first Pull Request and welcome to Amundsen community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/amundsen-io/amundsen/blob/main/CONTRIBUTING.md)

Copy link
Contributor

@kristenarmes kristenarmes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good overall! just had one comment that I realized based on your screenshot of the grouped notices

const { messageHtml, severity, payload } = notice;

if (payload) {
accum[messageHtml] ??= {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just noticed this in your screenshot in the PR description where it groups the notices with the same message but different severities into 1 - I'm thinking if the severity is different we should group those separately if possible, so by unique message and severity? I don't think that would happen for us in our cases, but not sure if it might for others who use this feature

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah this is a great point. Yeah I can group them by message + severity, let me get a fix up. Thanks for the find!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, took a few days to get back to this but the changes are now up and screenshots are updated. So it will now group by message and then sub-group by severity, which is then sorted to show up

Copy link
Member

@Golodhros Golodhros left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

if (notice) {
const { messageHtml, severity, payload } = notice;

/* eslint-disable no-param-reassign */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could get rid of this rule, we have better things to care about!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adjusted the rule to turn it off

}

const aggregateNotices = (notices) =>
notices.reduce((accum, notice: any) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any way to avoid this 'any'?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah should be able to, might've just been leftover from my first implementation :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mapped it to NoticeType

@Golodhros
Copy link
Member

Maybe I would add a count on the aggregated notices, something like a (X) at the end of the text.

@feng-tao
Copy link
Member

the feature looks great!

@jdslaugh
Copy link
Contributor Author

Maybe I would add a count on the aggregated notices, something like a (X) at the end of the text.

Ooh that's a good idea, yeah I can do that!

Signed-off-by: Josh Slaughter <[email protected]>
Signed-off-by: Josh Slaughter <[email protected]>
- Sorting of notices by severity
- Added a number next to show details if # of notices > 1
- Adjusted css for info-svg-icon to align it with others
- Turned off param-reassign rule

Signed-off-by: Josh Slaughter <[email protected]>
if (notice) {
const { messageHtml, severity, payload } = notice;

if (typeof messageHtml !== 'function') {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only case I'm not sure of is when messageHtml is a function and takes a resourceName. Not really sure what I would use for that case but if anyone has any ideas I can do it or if we assume it's not happening for this we can just ignore it I guess.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good question, I just checked and we have one instance where we were using this functionality at Lyft. I looked into this a bit and I don't think it would ever be a function type at this point. I included my investigation below, but TLDR I think this is fine to leave as you have it here

in the table detail page it passes the results from this function aggregateResourceNotices to the AlertList, and that function calls getResourceNotices. in there it transforms the notices that have function types as their messageHtml to call the function and set set the field to its string message. I investigated backward from the original implementation of function messageHtml fields here

Copy link
Contributor

@kristenarmes kristenarmes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great, thanks for all the updates!

I see there is a failure from betterer as the last thing, you can run npm run betterer under the directory frontend/amundsen_application/static to test locally. I'm not sure what the best solution is for this case bc I think this is what you tried to turn off...if it is too much of a pain to fix, I'm fine with you using the comment like you had before to bypass

@kristenarmes kristenarmes merged commit 73313b8 into amundsen-io:main Feb 29, 2024
9 checks passed
Copy link

boring-cyborg bot commented Feb 29, 2024

Awesome work, congrats on your first merged pull request!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:frontend From the Frontend folder
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants