Notifications, Ownership, And Permissions System Design

by Alex Johnson 56 views

Goal

The goal is to implement a comprehensive notification system, machine ownership model, and refined permission roles. This robust system will ensure that users are promptly informed about relevant events, machines are properly managed, and access is controlled effectively. A well-designed system for notifications, ownership, and permissions is crucial for maintaining a secure, efficient, and user-friendly environment. This design not only aims to enhance user experience but also to streamline administrative tasks and improve overall system management. By clearly defining roles and responsibilities, and by providing timely notifications, the system can prevent potential issues and ensure smooth operations. Furthermore, the flexibility of the system will allow for future scalability and adaptability to evolving business needs.

Database Schema

The database schema will form the backbone of our new system, and it is designed to efficiently store and manage data related to machines, issues, notifications, and user preferences. Let's walk through the proposed database schema in detail:

machines

  • Add ownerId (uuid, references user_profiles.id).

    The machines table will be extended with an ownerId field. This field, a UUID, will reference the id in the user_profiles table. This is a critical step in establishing machine ownership, allowing us to clearly define who is responsible for each machine. This addition facilitates better accountability and management of machines within the system. By linking machines to specific owners, we can easily identify the responsible party for maintenance, updates, and issue resolution. This also opens up possibilities for owner-specific notifications and permissions, enhancing the overall system functionality.

issue_watchers

  • issueId (uuid, references issues.id)

  • userId (uuid, references user_profiles.id)

  • Primary Key: (issueId, userId)

    The issue_watchers table will manage the relationship between issues and users who are watching them. It includes issueId and userId, both UUIDs referencing their respective tables. The primary key is a composite key (issueId, userId), ensuring that each user can watch an issue only once. This table is crucial for managing issue-specific notifications, ensuring that relevant users are informed about updates and changes. By tracking watchers, the system can send targeted notifications, reducing noise and improving the relevance of information delivered to users. This enhances collaboration and responsiveness in issue resolution.

notifications

  • id (uuid, pk)

  • userId (uuid, references user_profiles.id)

  • type (enum: issue_assigned, issue_status_changed, new_comment, new_issue)

  • resourceId (uuid, references issues.id or machines.id)

  • resourceType (enum: issue, machine)

  • readAt (timestamp, nullable)

  • createdAt (timestamp)

    The notifications table is designed to store all notifications generated by the system. It includes:

    • id: A UUID serving as the primary key.
    • userId: A UUID referencing the user_profiles table, indicating the recipient of the notification.
    • type: An enumeration of notification types, including issue_assigned, issue_status_changed, new_comment, and new_issue. This allows the system to categorize and handle notifications differently based on their nature.
    • resourceId: A UUID referencing either the issues.id or machines.id, depending on the resourceType.
    • resourceType: An enumeration indicating whether the notification is related to an issue or a machine.
    • readAt: A timestamp indicating when the notification was read by the user. Nullable, as notifications may not have been read yet.
    • createdAt: A timestamp indicating when the notification was created.

    This table provides a comprehensive structure for managing notifications, ensuring that users are informed about relevant events in a timely manner. The type and resourceType fields allow for flexible filtering and routing of notifications, while the readAt field helps track notification status.

notification_preferences

  • userId (uuid, pk, references user_profiles.id)

  • emailEnabled (boolean, default true)

  • inAppEnabled (boolean, default true)

  • notifyOnAssigned (boolean, default true)

  • notifyOnStatusChange (boolean, default true)

  • notifyOnNewComment (boolean, default true)

  • notifyOnNewIssue (boolean, default true) - Applies to Owned machines

  • watchNewIssuesGlobal (boolean, default false) - Applies to ALL machines

  • autoWatchOwnedMachines (boolean, default true) - Auto-add as watcher on new issues (Owner)

    The notification_preferences table allows users to customize how they receive notifications. It includes:

    • userId: A UUID serving as the primary key and referencing the user_profiles table.
    • emailEnabled: A boolean indicating whether email notifications are enabled (default is true).
    • inAppEnabled: A boolean indicating whether in-app notifications are enabled (default is true).
    • Specific notification preferences for different event types, such as:
      • notifyOnAssigned: Notifications for issue assignments.
      • notifyOnStatusChange: Notifications for issue status changes.
      • notifyOnNewComment: Notifications for new comments on issues.
      • notifyOnNewIssue: Notifications for new issues created on owned machines.
      • watchNewIssuesGlobal: A global setting to watch all new issues.
      • autoWatchOwnedMachines: Automatically watch new issues created for owned machines.

    This table provides users with granular control over their notification settings, ensuring they receive only the information they need, in the way they prefer. The default values are set to provide a balanced approach, but users can easily customize these settings to suit their individual needs. This level of customization enhances user experience and satisfaction with the system.

Logic & Actions

The logic and actions define how the system behaves in response to various events and user interactions. This section will outline the key actions and triggers related to issues and machines, providing a clear understanding of the system's operational flow. These actions are designed to ensure timely notifications, proper access control, and efficient issue management.

Issues

Let's discuss the logic and actions related to issues within the system. Understanding these processes is crucial for ensuring smooth operations and effective communication among users.

  • Create Issue:

    • Trigger new_issue notification to:
      • Machine Owner (if notifyOnNewIssue enabled).
      • Global Subscribers (watchNewIssuesGlobal enabled).
    • Auto-add Reporter as issue_watcher.
    • Auto-add Machine Owner as issue_watcher (if autoWatchOwnedMachines enabled).
    • Auto-add Global Subscribers as issue_watcher.

    When a new issue is created, the system triggers several actions to ensure that the right people are notified and kept in the loop. First, a new_issue notification is sent to the machine owner, provided they have enabled the notifyOnNewIssue preference. This ensures that machine owners are promptly informed of any issues affecting their machines. Additionally, if there are any global subscribers who have enabled the watchNewIssuesGlobal setting, they will also receive this notification. This is useful for users who want to stay informed about all new issues across the system.

    In addition to notifications, the system automatically adds certain users as issue_watchers. The reporter, who created the issue, is automatically added as a watcher to ensure they receive updates on the issue's progress. Similarly, the machine owner is added as a watcher if they have enabled the autoWatchOwnedMachines preference, ensuring they are kept informed of issues affecting their machines. Finally, global subscribers are also added as watchers, allowing them to monitor the issue closely.

    This multi-faceted approach ensures that all relevant parties are immediately notified and engaged when a new issue is created, facilitating faster resolution and improved communication.

  • Update Issue Status:

    • Trigger issue_status_changed notification to issue_watchers.

    When the status of an issue is updated, it's crucial to keep all interested parties informed. To achieve this, the system triggers an issue_status_changed notification. This notification is sent to all users listed as issue_watchers. This includes the reporter, machine owner (if applicable), assignee, and any other users who have manually subscribed to receive updates on the issue.

    By notifying all watchers, the system ensures that everyone is aware of the latest developments, facilitating better collaboration and faster resolution times. This simple yet effective mechanism keeps all stakeholders aligned and informed throughout the issue lifecycle.

  • Assign Issue:

    • Trigger issue_assigned notification to Assignee.
    • Auto-add Assignee as issue_watcher.

    Assigning an issue to a user is a critical step in the resolution process, and it's essential to ensure the assignee is promptly notified. When an issue is assigned, the system triggers an issue_assigned notification specifically to the assignee. This immediate notification ensures that the assignee is aware of their new responsibility and can begin working on the issue without delay.

    In addition to the notification, the system automatically adds the assignee as an issue_watcher. This ensures that the assignee receives all subsequent updates and comments related to the issue, keeping them fully informed of its progress. This automatic addition simplifies the process and ensures that the assignee remains engaged until the issue is resolved.

    By combining immediate notification with automatic watcher status, the system streamlines the assignment process and promotes efficient issue resolution.

  • Add Comment:

    • Trigger new_comment notification to issue_watchers (excluding comment author).

    Comments play a crucial role in issue resolution by providing additional context and updates. To keep all relevant parties informed, the system triggers a new_comment notification whenever a new comment is added to an issue. This notification is sent to all issue_watchers, ensuring they are aware of the latest discussions and developments.

    However, the system intelligently excludes the comment author from receiving the notification. This prevents the author from being spammed with notifications about their own comments, reducing unnecessary noise and improving the overall user experience. By targeting notifications to only those who need to be informed, the system ensures that users receive relevant updates without being overwhelmed.

  • Watch/Unwatch Issue:

    • Actions to toggle issue_watchers.

    Users need the flexibility to control which issues they are actively monitoring. To support this, the system provides actions to toggle issue_watchers. Users can choose to watch an issue to receive notifications about updates, or unwatch an issue to stop receiving notifications. This functionality allows users to customize their notification stream and focus on the issues that are most relevant to them.

    The watch/unwatch actions directly modify the issue_watchers table, adding or removing the user's association with the issue. This simple yet powerful feature empowers users to manage their engagement with issues, enhancing their overall experience and productivity.

Machines

Now, let's turn our attention to the logic and actions related to machines within the system. These processes ensure proper management and ownership of machines, as well as controlled access to machine-related information and actions.

  • Add Machine:

    • Require ownerId.
    • Permission: Admin only.

    Adding a new machine to the system is a critical administrative task that requires careful control. To ensure proper ownership and accountability, the system mandates that an ownerId be specified when a new machine is added. This ownerId links the machine to a specific user, establishing clear responsibility for its management and maintenance.

    Furthermore, the system restricts the ability to add machines to users with Admin permissions only. This ensures that only authorized personnel can add new machines, preventing unauthorized additions and maintaining the integrity of the machine inventory. By enforcing these restrictions, the system maintains a secure and well-managed environment for machine resources.

  • Update Machine:

    • Allow Admin to change ownerId.

    Updating machine details, particularly the ownerId, is another administrative task that requires controlled access. The system allows users with Admin permissions to change the ownerId of a machine. This functionality is essential for transferring ownership when responsibilities change or when machines are reassigned to different users.

    By limiting the ability to change ownerId to Admins, the system ensures that ownership changes are properly authorized and tracked. This helps maintain accountability and prevents unauthorized modifications to machine ownership. The ability to update machine details is crucial for maintaining an accurate and up-to-date inventory of machine resources.

UI Components

The user interface (UI) components are designed to provide users with intuitive and efficient ways to interact with the new notification, ownership, and permissions system. These components will be integrated into the existing UI, providing a seamless user experience. Let's explore the key UI components that will be implemented:

  • Machine Form:

    • Add Owner selection (Admin only).

    The Machine Form will be enhanced to include an Owner selection field, but this addition will be visible and accessible to Admin users only. This field will allow administrators to assign an owner to a machine when it is created or updated. The Owner selection will likely be a dropdown or a search field that allows Admins to select a user from the list of available users. This ensures that machines are properly assigned and managed within the system.

    By restricting the Owner selection to Admin users, the system maintains control over machine ownership and prevents unauthorized changes. This simple addition to the Machine Form provides a crucial administrative function, enhancing the overall management of machine resources.

  • Issue Details:

    • Display Owner, Watchers list, Watch/Unwatch button.

    The Issue Details view will be updated to display important information about the issue, including the Owner of the affected machine and a list of current Watchers. This provides users with a clear understanding of who is involved with the issue and who is receiving notifications about its progress. Displaying the Owner helps to establish accountability and provides a point of contact for further information or assistance.

    In addition to displaying the Watchers list, a Watch/Unwatch button will be added to the Issue Details view. This button allows users to easily subscribe to or unsubscribe from issue updates. By clicking the Watch button, a user will be added to the list of Watchers and will receive notifications about any changes or comments related to the issue. Clicking the Unwatch button will remove the user from the list, and they will no longer receive notifications. This provides users with granular control over their notification stream, allowing them to focus on the issues that are most relevant to them.

  • Notification List:

    • In-app notifications with "Mark as Read".

    A dedicated Notification List will be implemented within the application to provide users with a centralized view of their notifications. This list will display in-app notifications, allowing users to stay informed about important events and updates within the system. Each notification will include relevant details, such as the type of event, the affected resource, and the time it occurred.

    To help users manage their notifications, a "Mark as Read" function will be included. This allows users to indicate that they have reviewed a notification, reducing clutter and helping them focus on unread notifications. The Notification List will likely be accessible from a prominent location within the application, such as a notification icon in the header or a dedicated notifications page. This ensures that users can easily access and manage their notifications, staying informed and engaged with the system.

  • Settings:

    • Notification preferences form.

    A dedicated Notification Preferences form will be added to the Settings section of the application. This form will allow users to customize their notification settings, providing them with granular control over how and when they receive notifications. Users will be able to configure preferences for various notification types, such as issue assignments, status changes, comments, and new issues.

    The form will likely include options to enable or disable email and in-app notifications, as well as specific settings for different event types. For example, users may be able to choose to receive email notifications for high-priority issues only, or to disable in-app notifications during certain hours. This level of customization ensures that users receive only the notifications they need, in the way they prefer. The Notification Preferences form is a crucial component for empowering users to manage their notification experience, reducing noise and improving overall satisfaction with the system.

In conclusion, this system provides a robust framework for managing notifications, machine ownership, and permissions, ensuring a secure, efficient, and user-friendly environment. For further reading on system design best practices, check out this comprehensive guide.