Notification System

Goals

Expand NiFi bulletin functionality to inform users about all flow related matters and improve general communication through more immediate feedback on actions they perform.

Background and strategic fit

• Users must look in different UI locations depending on the source of a bulletin
  • System-level bulletins highlight the icon in the flow status bar 
  • Component-level bulletins are only visible on the component itself or within the bulletin board
• Component-level bulletins can go unnoticed if the user is not operating within view of the affected component
• Regardless of a bulletin’s significance, it is communicated the same way; therefore, it could be said those of particular importance are not given enough attention
• There are many cases where NiFi should provide or can improve messaging related to other data flow matters, as well as general feedback on user performed actions ¹ – all of which bulletins do not cover
• Awareness and acknowledgement of bulletins is not user specific
  • Multiple users operating the same flow can have incomplete pictures of a data flow’s health and status

¹  Unable to render Jira issues macro, execution error.

Assumptions

Requirements

User interaction and design

Introduce an enhanced system called Notifications that will provide:

• A single location where a user can see if there are any flow related issues
  • Expanded highlighting of issues in specific areas as they occur, as is currently done on canvas components
• A count next to a notification icon indicating how many are active/unresolved
  • A summary of active/unresolved notifications on hover and an action to access all notifications
• A Notifications area (currently Bulletin Board) – accessed by clicking the notification icon – expanded to allow searches by component name/type, notification type, etc.
• A tiered approach to UI behavior and required user interaction depending on the type of notification – see Importance levels detail table
• Notifications in real time as they occur and are resolved
• Additional context and relevant help for users to better understand and resolve issues
• Effective handling of notifications across multiple browser tabs ²

Changes to UI elements under proposed solution:

A user will receive notifications and interact with them in one of three ways. This will depend on an importance level assigned to all notifications.

Importance levels detail:

Importance levels will not be configured by the user. They will be programmatically set to prescribe a way for users to be informed of and interact with a specific notification.

The current Bulletin Level setting – to change to Notification Level under the proposal – consisting of debug, info, warn, and error will map to an importance level. This way, users will remain in control of what system/component-level notifications are emitted.

Examples of how notification levels would map to an importance level:

²  Unable to render Jira issues macro, execution error.

Example Use Cases

1. A new flow or component version is available (upgrade)
2. A flow version has been removed or tagged as obsolete
3. Registry connection status interrupted
4. Expensive framework tasks ³
5. Remote port connection status changes
6. Backpressure engagement on connections
7. Penalized flowfiles in a queue ⁴
8. Startup errors ⁵
9. Disk/repository space issues
10. Cluster status changes
11. When other users make changes to a flow
12. Notify user when other systems/integrations affect NiFi
13. New or updated schema available

³  Unable to render Jira issues macro, execution error.

⁴  Unable to render Jira issues macro, execution error.

⁵  Unable to render Jira issues macro, execution error.

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Not Doing