Notifications

Notifications

OneView tells a user when something needs their attention through an in-app notification, and optionally an email. In-app notifications require no configuration. Email delivery is optional and requires an administrator to configure both Redis and an SMTP connection first.

Every authenticated user gets both channels for their own account. There is no separate notifications:* permission — visibility is scoped to the signed-in user's own notifications.

What triggers a notification

In the current release, a notification is created when a report reaches a maker-checker approval level that requires your decision: every approver named on that level receives one. See Reporting for the approval workflow itself. Other events do not yet raise a notification.

The notification bell

The bell in the application header is available to every signed-in user. It shows an unread-count badge (checked automatically in the background) and, when opened, lists recent notifications with their title, body, and relative date. Unread items are highlighted with a dot and bolder text.

• Selecting a notification that links to a record (currently a report) opens that record and marks the notification read.
• Selecting a notification with no linked record just marks it read.
• Mark all read clears every unread notification for the current user.
• The panel closes on Escape or when clicking outside it.

Self-service email preference

Open My Account → Notifications (see Users, roles & permissions for the My Account page) to control Email me when I need to take action. This is on by default for every user. Turning it off stops email delivery for that user only; in-app notifications in the bell still appear regardless of this setting.

If the installation has not configured SMTP yet, the toggle still works but the page notes that email delivery is not set up — nothing will actually send until an administrator configures Settings → Email.

Settings → Email (SMTP)

email:read permits viewing whether an SMTP connection is configured and previewing the notification email template. email:manage permits testing and saving the connection, plus sending a real test email.

Email delivery requires Redis to be configured first. OneView sends notification emails through a Redis-backed queue, so the setup form will not accept an SMTP connection until Redis is connected — it shows a Redis is not configured notice with a link to Settings → Redis instead of the form. See Redis to configure that first. This is a deliberate order-of-operations check: without it, an SMTP connection would validate successfully but silently never deliver anything, because nothing would be dequeuing the emails.

Once Redis is configured:

1. Enter the SMTP hostname and port.
2. Username and password are optional, for a server that requires authentication.
3. Enter a From address and From name — every notification email is sent and branded using these, along with the installation's own name and colors.
4. Enable Implicit TLS for port-465-style implicit TLS. Leave it off for STARTTLS, typically port 587.
5. Select Test connection, then Use this connection to save it. As with Redis, OneView re-verifies the connection at save time rather than trusting the earlier test result.

Once configured, the page confirms the connection is set up. A user with email:manage can select Reconfigure in the page header to point OneView at a different SMTP server; there is no separate delete or disconnect action. Saved SMTP credentials are not displayed again — keep the approved value in the client's secret-management process.

Connection overview

Once email is configured, a Connection overview card is always visible on the page. It lists the non-secret configured facts — the from address, display name, authenticating username (if one is set), SMTP host and port, and encryption mode — alongside a live preview of exactly what a notification email looks like, rendered from the real template rather than a separate mockup.

A user with email:manage can also select Send test email in the page header to send a real message to their own signed-in account's address, confirming end-to-end delivery through the configured SMTP connection and Redis queue. The preview and test message both use generic sample content (a "Welcome to OneView" style message), not a real notification, so reviewing them never exposes a customer record.

What a notification email looks like

Every notification email uses the same branded template. It greets the recipient by first name and an initial of their last name — for example "Hi Eddy U.," — falling back to a generic greeting when no name is available.

When a notification is about a specific record from a module that supports a direct link, the email includes a button with meaningful text linking straight to that record. Today, a notification that a report needs the recipient's decision includes a Review report button linking directly to that report; see Reporting for the approval workflow. Support for linking directly to other kinds of records is expected to expand over time.

Every notification email closes with a footer note pointing back to My Account → Notifications (see Users, roles & permissions for the My Account page) and a copyright line for the installation.

Failure behavior

A notification's in-app record is always created, even if email delivery is impossible or fails. Email is best-effort: if the recipient has email notifications enabled and SMTP is configured, OneView queues the email through Redis; if the queue is unreachable, that failure is logged and does not block or fail the action that triggered the notification. Nothing in OneView depends on a notification email actually arriving.