Explore Adding Notification Center functionality

FragmentedPacket commented 3 years ago

Environment

Python version: Any
Nautobot version: Any

Proposed Functionality

Provide a notification center within Nautobot. This would be similar to sites such as Github that has a bell in the top right that will show a dot to display an unread notification exists as well as a list view that mark things as unread, etc.

Use Case

This came to mind during @jvanderaa's team presentation for the getting started with Nautobot that provides a check list for new Nautobot installs on what users should create/do with a new server installation such as creating a site, manufacturer, device type, etc. Basically all the dependent objects required to get started adding objects into Nautobot.

I don't think that is the only use case, but it would also be tremendously valuable to provide notifications for jobs so the user is aware a job has started, completed, errored out, etc. without having to explicitly check the jobs page. We're starting to use jobs for a lot of functionality and if I was to kick off a job, it would be nice to receive notifications on the status of it. Also, when scheduled jobs is implemented, obtaining notifications of the outcome will be valuable.

I believe this would also provide value to plugin authors to be able to notify users of plugin specific notifications. Maybe the configuration compliance would pop up a notification when specific devices are non-compliant or a device transitions from compliant to non-compliant, etc.

This could also include if a queue becomes backed up or is an errored state. Or potentially a webhook is in a stuck state, etc. I guess it could also be system level notifications as well. I think there is a lot of possibilities that are out there that provide value to end users and administrators of Nautobot.

Could potentially be extended in the future to provide where the notification is sent to such as email, PagerDuty, webhook, etc.

Database Changes

Not sure?

External Dependencies

Most likely some Django related notification package.

https://github.com/django-notifications/django-notifications

itdependsnetworks commented 3 years ago

Ironically, this came up twice in the last two days.

jathanism commented 3 years ago

This is potentially very interesting. Seems like this could warrant some discussion. It seems to me that this could be incredibly useful on that final point:

Could potentially be extended in the future to provide where the notification is sent to such as email, PagerDuty, webhook, etc.

jedelman8 commented 3 years ago

For initial implementation, one idea is to implement this for Jobs and allow plugins to inject content here as well.

For Jobs, that would be notifications for:

When Jobs are executed
When Jobs are Approved or Denied (blocked by #125 although it'll be in this release too)
When Jobs are Scheduled (blocked by #374 although it'll be in this release too)

Any feedback @FragmentedPacket @itdependsnetworks ?

FragmentedPacket commented 3 years ago

To go along with the first bullet point, the final outcome would be great.

glennmatthews commented 3 years ago

A few questions to clarify the requirements:

It sounds like most of the Job use cases described above are for notifying a specific user, typically the initial requestor of a Job. Are multi-user (list of individuals, or by-group such as "all admins") or all-users notifications also part of the requirement?
It seems like "system-level" notifications ("task queue overfull", "webhook send error", etc.) would need to be configurable, at a minimum "enable/disable" and "send-to which user(s)" would need to be configurable for each of these. Do we need some sort of registry of available notification types to provide a general pattern here, or are ad-hoc individual configuration flags sufficient? Does this need to be configurable via the GUI or Admin panel, or is configuration via nautobot_config.py sufficient?

jedelman8 commented 3 years ago

It sounds like most of the Job use cases described above are for notifying a specific user, typically the initial requestor of a Job. Are multi-user (list of individuals, or by-group such as "all admins") or all-users notifications also part of the requirement?

I would think "all users" for now. In the future, possibly anyone with the same group or higher... This means even at some point when Jobs are permissioned, users would see jobs executing, but couldn't click through.

This begs the question for now, are notifications hyperlinks in the initial implementation? Do you know if that would be an issue? Thinking of references and links that may go away.

It seems like "system-level" notifications ("task queue overfull", "webhook send error", etc.) would need to be configurable, at a minimum "enable/disable" and "send-to which user(s)" would need to be configurable for each of these. Do we need some sort of registry of available notification types to provide a general pattern here, or are ad-hoc individual configuration flags sufficient? Does this need to be configurable via the GUI or Admin panel, or is configuration via nautobot_config.py sufficient?

This is interesting. I don't think we do this now, but it would be neat if a user, in their user profile, could enable/disable system notifications. Even when we do this, I could see starting with globally enabling/disabling system-level notifications for all users, then layer in, for which systems. Per the above, users could subscribe to them in their profile then.

Also, how do long we keep items in the Notifications?

glennmatthews commented 3 years ago

Need to think about managing "notification spam" here. If all users are notified for every job that is executed, that could result in a lot of noise for each user. Especially as scheduled jobs become more widespread - in one existing deployment I'm aware of, there are a set of three Jobs that are executed on an hourly basis - as a user I don't need (3x24) 72 notifications a day for a system job that doesn't particularly interest me.

Yoyasp commented 3 years ago

Could we maybe use the permission system to identify which users are receiving what notification? This would also make it possible to let plugins write custom notifications.

Besides the user notification i think it would be a great addition to also be able to trigger webhooks when a scheduled job fails (with #374 in mind)

erjac77 commented 3 years ago

Why not take the opportunity to migrate to ASGI and use Websockets to send asynchronous notifications?

https://docs.djangoproject.com/en/3.1/howto/deployment/asgi/ https://hackernoon.com/how-to-improve-django-31-view-performance-with-async-support-vp293488 https://dev.to/alexoleshkevich/websockets-in-django-3-1-532o

jedelman8 commented 3 years ago

This particular issue is migrating to an Exploration/Spike with development of it to come in the next release.

cmacnevin commented 2 years ago

We've also asked for this. The Reservations plugin needs a better place then a banner to notify admins that a reservation approval is pending. Additional uses I can see include:

Improved Device Type flow: user submits a device type which won't be approved until someone has approved it.
User can 'track' objects, such as a prefix, dynamic group, site, location.. and any changes regarding that object are notified. This would be especially useful if it could generate notifications like pager duty or Slack, as someone mentioned above

lampwins commented 2 years ago

This is still a little bit nebulous, and several distinct features have been proposed in this thread. I am going to treat this issue as the epic and begin breaking out targeted stories into separate issues. In our first pass at this sort of functionality, we will target the infrastructure to define events, route them to user groups, and for those users to view those notifications in Nautobot. Both core and plugins/apps will be able to utilize new interfaces for managing these notifications, but we will stop short of implementing any sort of approval workflow system in core, as a part of this functionality. Our version control app is targeting that specific feature set.

[ ] As Mary the Manager, I want a place to go in Nautobot where I can see a consolidated list of notifications that are relevant to me so that I can review those notices and begin taking action on them.
[ ] As P.D. the Plugin Developer, I want a defined interface for creating targeted notifications so that my users can be alerted and act upon those notices in a consistent manner.
[ ] As Austin the Network Automation Engineer, I want the Notification Center to allow me to define user groups so that I can use those groups to route notification events to those users.
[ ] As Austin the Network Automation Engineer, I want the Notification Center to manage registered event types so that I can enable certain events and route them to particular users.
[ ] As Patti the Platform Admin, I want to be able to configure alert settings so that I can control how notifications are sent to email, chatops, other alerting platforms like Pagerduty, etc.

itdependsnetworks commented 2 years ago

This is in line, and even further (Patti use case) than my expectations

cardoe commented 1 year ago

This would probably flow well with the React based UI and having a service worker there for this and using the web based Notifications API.

nautobot / nautobot