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 1 – 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
1 NIFI-3394 - Getting issue details... STATUS
Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | ||||
| 2 |
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 2
Changes to UI elements under proposed solution:
| Current Element | Replace With |
|---|---|
"Bulletin" (term and icon)
| Notification
|
| "Bulletin Board" (menu option) | Notifications |
| "Bulletin Level" (configuration label) | Notification Level |
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 Level | UI Behavior | Required User Interaction |
|---|---|---|
| Low |
| None |
| High |
| None |
| Critical |
| Message requires user acknowledgement to remove (e.g., "Dismiss", "View details," "Check configuration", etc.) |
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:
| Notification Level | Importance Level | Usability Notes |
|---|---|---|
| Debug | Low | Not necessary to interrupt user's workflow |
| Info | Low | Not necessary to interrupt user's workflow |
| Warn | High | Useful to immediately inform via on-screen message, but allows user to continue working at their discretion |
| Error | Critical | Reserve for serious conditions when immediate attention is necessary to maintain data flow health |
2
NIFI-94
-
Getting issue details...
STATUS
Example Use Cases
- A new flow or component version is available (upgrade)
- A flow version has been removed or tagged as obsolete
- Registry connection status interrupted
- Expensive framework tasks 3
- Remote port connection status changes
- Backpressure engagement on connections
- Penalized flowfiles in a queue 4
- Startup errors 5
- Disk/repository space issues
- Cluster status changes
- When other users make changes to a flow
- Notify user when other systems/integrations affect NiFi
- New or updated schema available
3 NIFI-88 - Getting issue details... STATUS
4 NIFI-767 - Getting issue details... STATUS
5 NIFI-860 - Getting issue details... STATUS
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
| Should NiFi maintain a history of all notifications independent of the standard 5m window? To what level of detail? Some possible options:
|