Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Notifications: improve wording #14893

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

Closed
13 tasks done
mtojek opened this issue Oct 1, 2024 · 4 comments
Closed
13 tasks done

Notifications: improve wording #14893

mtojek opened this issue Oct 1, 2024 · 4 comments
Assignees
Labels
good first issue Easily solved issues suitable for starters and community contributors

Comments

@mtojek
Copy link
Member

mtojek commented Oct 1, 2024

Follow-up on an old PR -

We need to improve the wording of our notifications. The rendered testdata can be a reference point.

@mtojek mtojek added this to the improvement milestone Oct 1, 2024
@mtojek mtojek added the good first issue Easily solved issues suitable for starters and community contributors label Oct 1, 2024
@SasSwart
Copy link
Contributor

SasSwart commented Oct 1, 2024

Requesting a mutex on this one. I'll assign it to myself as soon as my access is granted, which I will also request shortly.

@dannykopping
Copy link
Contributor

🔒

@SasSwart
Copy link
Contributor

SasSwart commented Oct 6, 2024

Feedback so far:

Simpler formatting updates have been made in #14967, which is under review.

I've looked into how the notifier works so that I can understand how to make more complicated changes. I plan two more change sets.

The first will contain updates to the notification templates where the data that should be added is already part of the notification payload.

The second will deal with notifications for which such additional information is not yet in the payload object. For this final change I will need to look into how to safely add more information to the payload. Because we do not support empty fields in our templates (

Option("missingkey=invalid").
), this would be a backward incompatible change as far as I can tell. We would need to version the payload.

I'm also curious about the risk of the Payload struct becoming a kind of god-struct. As it becomes larger over time to support more diverse notifications, it might start to contain information from disparate domains that might be cumbersome to populate in all cases.

cc @mafredri @dannykopping @mtojek

Edit:
Figured out how the payload handles generic data. Updating the templates to use it will be simple enough. I'll try to get the templates updated to use the requested information and then produce updated rendered golden files. After that, I'll find where these specific notifications are enqueued and figure out how to inject the necessary data.

dannykopping pushed a commit that referenced this issue Oct 9, 2024
…14967)

This Pull request addresses the more trivial items in
#14893.
These were simple formatting changes that I was able to fix despite
limited context.

Some more changes are required for which I will have to dig a bit deeper
into how the template contexts are populated. I'm happy to add those to
this PR or create a subsequent PR.
@SasSwart
Copy link
Contributor

@mafredri Are we happy to close this one? I've merged multiple PRs that address all of these.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Easily solved issues suitable for starters and community contributors
Projects
None yet
Development

No branches or pull requests

5 participants