Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt

Use this file to discover all available pages before exploring further.

Repeatable manual test plan for verifying messaging, notifications, and inbox behavior before or after changes. For E2E automation, see tests/e2e/platform/messaging.spec.ts and tests/e2e/platform/notification-delivery.spec.ts. References: tests/e2e/fixtures/auth.fixture.ts, docs/testing/TESTING_SETUP_AND_RUN.md (env vars and authenticated E2E).

1. Messaging

1.1 Happy path

  1. Navigate to /messaging.
  2. Confirm empty state when no conversations: “No conversations yet”, “Start a new conversation to begin messaging.”, “Start a conversation” button, and ”# Browse Channels” link.
  3. Click Start a conversation; confirm the create-conversation dialog opens (DM / Group / Channel tabs or email input for DM).
  4. Create a DM: enter an org user email, submit; confirm the new conversation appears in the left list and the right pane shows the thread (or placeholder to type).
  5. Type a message in the composer and send; confirm the message appears in the thread.
  6. (Optional, two users) From another user session, confirm the message is visible and realtime delivery works.

1.2 Channels

  1. From /messaging, click Browse Channels.
  2. Confirm the channel browser (dialog or list) opens and shows joinable channels.
  3. Open a channel; post a message; verify visibility and permissions (e.g. only members see private channels).

1.3 Error handling

  1. Invalid email (create DM): Enter an email that is not a user in the org; confirm a user-friendly error (no raw stack trace), e.g. “No user found with that email in your organization”.
  2. Very long message: Send or attempt to send an overly long message; confirm validation or truncation and a safe error message.
  3. Send with no recipient: If the UI allows submitting without a valid recipient, confirm a clear validation message.
  4. Confirm all user-facing errors use safe, sanitized messages (no internal implementation details).

2. Notifications — header

  1. Confirm the bell icon in the header shows an unread count badge when there are unread notifications (and no badge when zero).
  2. Click the bell; confirm the dropdown (desktop) or bottom sheet (mobile) opens.
  3. Confirm the panel shows: header “Notifications”, optional “Mark all read” when there are unread items, list of notifications (or empty state), “View all notifications”, and “Notification preferences” (or “Manage preferences”).
  4. When there are no notifications, confirm the empty state includes a link or button to Manage preferences (or equivalent) so users can configure notification channels.

3. Notifications — full page

  1. Navigate to /notifications.
  2. Confirm tabs: All (with count), Unread, Read; search (“Search notifications…”); Filter button; Preferences and Delete read in the toolbar.
  3. Use Filter; confirm options (e.g. by type, date range) and that active filters are visible (chips or summary).
  4. Select read notifications (or “Select all” when only read); click Delete read; confirm a confirmation dialog (“Delete X read notifications?”) with Cancel/Delete.
  5. Confirm Delete read is disabled when there are no read notifications.

4. Unified Inbox

  1. Navigate to /inbox.
  2. Confirm tabs: All, Notifications, Tasks, Approvals, Signatures, Messages.
  3. When the inbox is empty, confirm the empty state: “You’re all caught up!” and “No pending items in your inbox”, plus one line of guidance (e.g. “Tasks and approvals will appear here when assigned to you”) or a link like “Check your notifications”.
  4. From the Notifications tab (or All), confirm a secondary action: Open full notifications page or Manage preferences linking to /notifications or /notifications/preferences.

5. Dashboard widgets

  1. On the dashboard (Home), locate the Pending Actions widget.
  2. Confirm the notification count matches the header bell unread count.
  3. Confirm a View notifications link or icon next to the notification count that goes to /notifications.
  4. Locate the Notifications widget; if it shows a limited list (e.g. 5), confirm a label like “Recent 5” or “Latest notifications” and a prominent “View all notifications”.

  1. NotificationCenter → preferences: From the bell dropdown, click “Notification preferences” (or “Manage preferences”); confirm navigation to the correct preferences route (e.g. /notifications/preferences or /settings/notifications).
  2. Inbox → full notifications: From Inbox, use the link to the full notifications page; confirm navigation to /notifications.
  3. Batched toast: When multiple notifications arrive in a short time, confirm a batched toast (e.g. “X new notifications”) with an action View inbox or View notifications that navigates to /inbox or /notifications on click.

7. Mobile (optional)

  1. Resize to a narrow viewport (e.g. 375px) or use a real device.
  2. Notifications: Open the bell; confirm the bottom sheet opens and is usable; confirm “View all” and “Manage preferences” are accessible.
  3. Inbox: Confirm tabs (All, Notifications, Tasks, etc.) scroll horizontally or collapse so all options are accessible; confirm “Select all” and bulk actions have adequate touch targets (≥ 44px).
  4. Messaging: Confirm the conversation list and thread pane behave (e.g. list full-width, then thread; or swipe back to list); confirm “Start a conversation” and “Browse Channels” are tappable.

Environment and auth

  • For local E2E, use env vars as in TESTING_SETUP_AND_RUN.md (e.g. TEST_USER_ADMIN_EMAIL, TEST_USER_ADMIN_PASSWORD, TEST_ORG_SLUG). Authenticated Playwright specs use the chromium-authenticated project or loginAsTestUser from auth.fixture.ts.
  • For manual QA, log in as a user with permission pf.messaging.view and access to notifications; use an org that has at least one other user for DM tests.