Documents, Notifications & Support

1. Document Management in SamvraCore

The Documents module centres on the DocumentsPage, a workspace for uploading, organising and retrieving files inside a tenant. Users add files either through an explicit upload action or by drag-and-drop, and the interface presents stored items in a navigable folder tree rather than a flat list.

Beyond storage, the module is built to view what it holds. It includes an image viewer that supports working with screenshots and images, and documents can be rotated in place so a sideways scan reads correctly without re-uploading. Files can also be moved between folders as the organisation of a workspace evolves.

A defining capability is that documents are not isolated: they can be attached to records elsewhere in the ERP. The module tracks this as a linked entity, so a file can be bound to the business object it belongs to.

Typical workflow

1. Open DocumentsPage and navigate to or create the target folder.
2. Drag a file into the browser, or use the upload control.
3. Attach the uploaded document to the relevant record so it is discoverable from that record.
4. Rotate or preview the file in the viewer if it is an image or screenshot.

The backend exposes document folders and attachments through dedicated APIs implemented in document_management_controller.go, which the frontend page consumes for every create, move and attach operation.

2. Folders, Navigation and Linked Entities

Organisation in the Documents module is hierarchical. There is a root level and sub-folders beneath it, and the interface provides parent folder navigation so a user can move up and down the tree. Because the folder tree is the primary structure, grouping related files is a matter of placing them in the right folder rather than tagging them individually.

The single most important integration concept is linked-entity tracking. A document does not only live in a folder; it can be associated with a specific business record elsewhere in the system. This is what lets a file behave as an attachment on another object instead of a standalone upload. The same underlying attachment capability is reused by other modules — for example, support tickets can carry attached documents.

Why linking matters

• A contract scan can be kept beside the contract record.
• Supporting paperwork can travel with the transaction it justifies.
• Files remain centrally stored and governed while still being reachable in context.

Moving a document between folders changes its organisational home without breaking its links, because the folder location and the linked entity are distinct pieces of information. This separation lets administrators reorganise the folder tree over time while the record associations stay intact. All of this folder and attachment behaviour is served by the document folders and attachments APIs, keeping the client a thin consumer of a consistent backend model.

3. Storage Backends: Local and S3

Document bytes are not written by the controller directly; they pass through a storage abstraction in the pkg/storage/ package. This package supports two concrete backends: the local filesystem and S3 object storage. The abstraction means the rest of the application treats document storage uniformly regardless of where the bytes physically reside.

The two backends suit different deployment shapes. The local filesystem backend fits a single self-contained installation where files live on the same host as the binary. The S3 backend fits deployments that want durable, off-host object storage, or that run where local disk is ephemeral.

How it fits the architecture

• The document_management_controller.go handles folder and attachment metadata.
• The pkg/storage/ layer handles the physical persistence of file content.
• Choosing local versus S3 is a storage-backend decision, not a change to how users interact with documents.

This same storage concept appears elsewhere in the platform: backup destinations also offer local and S3 targets, reflecting a consistent approach to where the product keeps large or binary data. For an operator, the practical consequence is that document handling can scale from a laptop-style single-host install to a cloud deployment backed by object storage, without the Documents module itself needing to change behaviour. The separation of metadata from byte storage is a deliberate design that keeps the module portable across the platform's supported deployment targets.

4. In-App and Email Notifications

The Notifications module delivers messages through two channels. In-app notifications surface inside the application on the NotificationsPage, giving users a running record of events relevant to them. Email notifications are sent out of band through the email subsystem in pkg/email/, which supports SMTP and Mailgun as transport.

Having both channels means a user can be alerted even when they are not logged in (via email) while still retaining an in-app history they can review later. The in-app list includes an unread-only filter, so a user can collapse the view down to items that still need attention and work through them.

Email transport in context

Email delivery depends on configuration elsewhere in the platform. The Settings area provides SMTP email configuration with documented examples for providers such as Amazon SES, Gmail, Outlook / Office 365 and SendGrid, and supports both TLS (STARTTLS) and SSL connections. The notification layer builds on this configured transport to actually send mail.

In practice, a state change in a module — for example an approval that needs action — can produce an in-app notification the user sees on the NotificationsPage and, where enabled, a corresponding email. The combination of an immediate in-app entry and an optional email is what makes notifications reliable across the different ways a user might be engaging with the ERP at any given moment.

5. Per-User Notification Preferences

Notifications are governed by preferences held per user, so two people in the same organisation can be alerted differently. The available preference switches cover email, push, weekly digest, marketing emails and task reminders. Each is an independent control, letting a user opt in to the categories they value and silence the rest.

These same preferences are exposed through the Settings area as notification preferences, confirming that preference management is a first-class, user-facing configuration rather than a hidden default. Because they are per-user, they respect the reality that an administrator, an accountant and a field employee want very different volumes and types of alert.

What each preference governs

• Email — whether transactional notifications reach the user by mail.
• Push — push-style alerting.
• Weekly digest — a periodic summary rather than per-event mail.
• Marketing emails — promotional messages, kept separate from operational alerts.
• Task reminders — nudges tied to assigned work.

Separating marketing from operational categories is deliberate: a user can keep receiving task reminders while turning off marketing, which matters for both usability and consent. Combined with the unread-only filter on the in-app list, these preferences give each user control over both the volume and the channel of what reaches them, reducing noise without hiding items that genuinely need a response.

6. Customer-Facing Support

The Support module has a customer-facing side built around raising and tracking tickets. A customer creates a ticket on the CreateTicketPage, reviews everything they have raised on MyTicketsPage, and works a single ticket through the TicketDetailPage.

The ticket detail view distinguishes between two kinds of response. A public reply is communication intended for the customer, while an internal note is visible to support staff only. This split lets agents record context, caveats or handover notes without exposing them to the person who raised the ticket. Tickets can also carry attached documents, reusing the platform's attachment capability so screenshots, logs or files can accompany the conversation.

Typical customer journey

1. The customer opens CreateTicketPage and describes the issue, optionally attaching documents.
2. They track open and historical tickets from MyTicketsPage.
3. On TicketDetailPage they read public replies from support and add follow-up information.

Because attachments flow through the same document-attachment mechanism used elsewhere, a support conversation can be enriched with evidence without a separate upload system. The public-reply versus internal-note distinction is the key design element that makes a single ticket serve both as a customer communication channel and as an internal working record for the support team.

7. Internal Support Portal and Team Management

The internal side of Support gives staff the tools to triage and resolve what customers raise. The SupportDashboard provides an overview, while SupportTickets and SupportTicketDetail are where agents do the work. From these views agents can assign a ticket, set priority levels and ultimately resolve it.

Staffing is handled through SupportTeam management, which defines the team that handles tickets. At the platform level, the super-admin console additionally offers a Manage Support Staff capability, reflecting that support personnel can be governed both within an organisation and across the platform.

From raised to resolved

1. A customer ticket arrives and appears for the support team.
2. An agent assigns it, sets a priority level to reflect urgency, and investigates.
3. The agent records internal notes for context and sends public replies to the customer.
4. Once addressed, the agent marks the ticket resolved.

The internal portal and the customer-facing pages are two views of the same tickets: a customer sees their own tickets and public replies, while agents see the dashboard, assignment, priority and internal notes. This shared-ticket design, together with priority and assignment controls, is what turns individual customer requests into a managed queue the support team can work systematically.