[feature] Add a dedicated view for managing notification preferences

[pandafy]

Add a dedicated admin view to allow the current logged in user to change their notification settings, we can then add a link like "change notification preferences" somewhere in the notification JS widget, this would be great for UX

From #69 (comment)

Depends on #255.
This new page must not be an admin page, also non staff users must be able to access it.
This page shall use the REST API to fetch and modify notification settings.

Modification of settings must be done only when actual changes are done, so when saving, the code must be smart enough to understand what HTTP requests it must make to change the settings (avoid generating a ton of useless HTTP requests).

---

We need to implement a solution that enables users to easily manage their notification preferences.

The shortcoming of the current solution
NotificationSettings are shown as an inline to the UserAdmin page. When a user is an admin for multiple organizations, or a superuser, the number of notification settings becomes tremendous, thus hurting the performance and usability of the UserAdmin view.

Proposed Solution

• Add a dedicated view for managing users' notification preferences.
• Add a link to this view in the notification widget. Clicking on this link should open the notification preferences page for the logged-in user.
• Add a link to this view in the UserAdmin change page. Clicking on this link should open the notification preferences of the selected user.
• View Permissions:
  • Allow superusers to change the notification preferences of any user
  • Allow non superadmin users to change only their notification preferences.

Open for Discussion
UI:

• In the new view, we can render notification settings in a table (as it is done now). But, we should allow filtering the table, e.g. OpenWrt's Table of Hardware. This allows users to quickly find the notification setting. It will be great if we can use autocomplete fields for searching.
• We can group notification preferences by organizations:
  E.g.:

+---------------------------------------+
| Organization1                         |
+---------------------------------------+
| +---------------------+-----+-------+ |
| | Notification Type 	| Web | Email | |
| +---------------------+-----+-------+ |
| | Ping Problem        | [ ] | [ ]   | |
| | Ping Recovery       | [ ] | [ ]   | |
| +---------------------+-----+-------+ |
+---------------------------------------+
| Organization2                         |
+---------------------------------------+
| +---------------------+-----+-------+ |
| | Notification Type 	| Web | Email | |
| +---------------------+-----+-------+ |
| | Ping Problem        | [ ] | [ ]   | |
| | Ping Recovery       | [ ] | [ ]   | |
| +---------------------+-----+-------+ |
+---------------------------------------+

Implementation details:

• To account for systems which have a large number of organizations, we shall make the widget capable of loading multiple pages of notification settings

[nemesifier]

I think the expected outcome here must be stated more explicitly.
From this page the user shall be able to:

• disable all notifications for all orgs
• disable only email notifications for all orgs
• after disabling all notifications, it shall be possible to enable notifications for a particular organization if the user wants to
• if both email and web notifications are disabled globally, it will not be possible to modify settings for the organizations, those shall be disabled

The UI must make this process easy to manage, hiding the complexity of the different settings and showing more details only when needed (eg: show widgets that allow enabling/disabling all web and email notifications for an org, but allow expanding the details to be able to select which particular notifications to enable/disable).

[nemesifier]

Another important point:

• as we discussed, this must be a non-admin page
• if the user tries to open the page when not authenticated, it shall be redirected to /accounts/login/
• after logging in, the user shall be directed to this page, this will likely require a change in openwisp-users

[Dhanus3133]

Summary of Notification Preferences Page UI/UX

The Notification Preferences UI allows users to manage their notification settings for different organizations. Here is how the UI works

Current UI Functionality

1. Organization Expansion/Collapse

   • By default, all organizations are unexpanded.
   • Users can expand an organization by clicking on it.
   • If a user has only one organization, it is expanded by default.

2. Global Settings

   • There are two global settings: Email and Web.
   • Enabling or disabling these global settings updates the global preferences of the user with a REST API call.
   • A toast notification confirms that settings have been updated successfully (or not, in case of errors).
   • When a global setting (Email or Web) is disabled, all related organization-specific notification settings are dimmed and cannot be edited until re-enabled.

3. Organization-Specific Notification Settings

   • Notification settings are displayed in a table for each organization.
   • Users can check or uncheck notification types to update settings instantly via REST API.
   • A toast notification confirms that settings have been updated successfully (or not, in case of errors).
   • There is a toggle at the top of each organization’s section to enable or disable all notification settings for that organization with a single click, one click generates one REST API request and shows the notification toast on save success/error.

UI Wireframes

[Figma Design]: This link directs you to our main Figma design file. It contains all the visual elements and layout.

[Prototype]: This link takes you to the interactive prototype of our application. The prototype simulates the user experience by linking various screens and demonstrating the flow of the page. Note that only the global email notification check and first notification email settings are interactive.

[nemesifier]

@uradotdesign @avocadodavinci looking forward to your feedback on this task we've been working on.

[avocadodavinci]

@nemesifier Here is some feedback on the proposed solution, along with a proposal of our own that builds on what you've shared

Notification Management in OpenWisp

The Problem

Users of OpenWISP are overwhelmed by an overabundance of notifications. To disable these, they currently need to navigate to each device's overview page and disable notifications individually from there. This process is time-consuming and inefficient, especially as the number of devices and organizations grows.

The Proposed Solution from OpenWISP

Open WISP's proposed solution involves creating a new page dedicated to notifications.

On this page, users have two main options for managing their notifications:

1. Globally Disable Notifications

• Email Notifications
• Web Notifications (through the OpenWisp dashboard)

2. Customize Notification Preferences for Each Organization

• Each organization is listed with a dropdown menu.
• Within that dropdown, specific notifications are listed e.g. Configuration ERROR, Configuaration applied PROBLEM
• Each notification item includes two checkboxes (Email & Web) as shown below. Users can toggle these checkboxes on or off according to their preferences.

Potential Issues with this Proposed Solution

While setting notifications globally is a good idea, there are several potential issues with this proposed solution:

1. Global vs. Organization-Level Settings Conflict:
   • Issue: It was proposed that when notifications are globally disabled, users won't be able to adjust notification settings for individual organizations. This means if global notifications are turned OFF, users won't have the option to customize notification preferences for specific organizations. The rationale behind this decision isn't clear to me, it may be due to technical constraints or specific design choices.
   • Impact: This can be frustrating as the network grows. If a user has ten or more organizations and only wants to receive notifications for a single issue in one of those organizations, they would need to go into each organization and disable everything except that one notification. This is cumbersome and time-consuming.

Suggested Improvements from Ura

To address the problem and improve the user experience, we propose the following enhancements:

1. Global and Organization-Specific Toggles:

• Solution: Implement a dual notification system with global and organization-specific settings. Users can globally disable all notifications but still enable specific notifications for individual organizations.

Solution in deatil

Below is a representation in markdown of how the page will look

---

Global Settings

Web Notifications

• Switch On/Off: When toggled on, users can manage specific notifications:
  • Warning
  • Info
  • Alert

Email Notifications

• Switch On/Off: When toggled on, users can manage specific notifications:
  • Warning
  • Info
  • Alert

Organizations

Organization 1

• Web Notifications: [Switch On/Off]

  • When the switch is toggled on, users can check or uncheck specific notifications:
    • Warning
    • Info
    • Alert

• Email Notifications: [Switch On/Off]

  • When the switch is toggled on, users can check or uncheck specific notifications:
    • Warning
    • Info
    • Alert

---

Global Settings

The first section will be labeled "Global Settings." Within this section, there are two dropdowns: one for "Web" and another for "Email," each accompanied by a switch that users can toggle on or off. Activating these switches will globally enable or disable notifications across all organizations. Here's a representation of how it might look:

---

Note: The image is sourced from Mobbin and are from the app Frame available at https://www.frame.so/.

---

Dropdown Settings: Specific Notifications

When the user opens the dropdown, there will be a list of specific notifications that they can turn on or off using checkboxes. These changes will be applied globally. See the image below for a high fidelity visual of this

---

Note: The images are sourced from Mobbin and are from the app Frame available at https://www.frame.so/.

---

Organizational Settings

Directly below the "Global Settings," there will be a dedicated section for "Organizations." Within this section, users will find a list of all organizations within the network. Each organization will have individual settings for Web and Email notifications.

In contrast to the proposal from OpenWISP, this solution allows users to toggle switches back on even when global settings are applied. For instance, if a user has turned off email notifications in the global settings, they can still visit an organization's settings and toggle email notifications back on. This action overrides the global settings by flipping that switch to 'on' for the specific organization. Importantly, this adjustment does not restore notifications for all other organizations; it only affects the organization that was toggled back on.

Saving Preferences

To save their preferences, users will find a convenient "Save Preferences" button positioned both at the bottom and the top of the page similar to 'Save changes' button in the example below

---

Note: The images are sourced from Mobbin and are from the app Qatalog available at https://qatalog.com/

---

After saving changes, users will receive a toast popup confirming that their preferences have been successfully updated.

---

Note: The images are sourced from Mobbin and are from the app Qatalog available at https://qatalog.com/

---

Note: If a user navigates away from the preferences page without saving their changes, they will be prompted to either save their preferences or proceed without saving. This serves as an extra layer of security to make sure the user saves their preferences.

Further Considerations

To further refine the proposed solution, we should consider the following questions and suggestions:

When will users first define their notification preferences?

• Question: Is this something that will be done during the initial configuration process, or is the default setting for all new configurations going to be to receive notifications?
• Consideration: Defining when and how users set their initial preferences can help streamline the notification management process and ensure users are not overwhelmed from the start.

Defining Types of Notifications:

• Suggestion: It would be valuable to better define the types of notifications. For example, there could be three categories: Warning, Info, and Error. By having these different types of notifications defined you could group them together in the dropdown settings to make them easier for the user to understand. These categories should also be explained in more detail on the notification page, clarifying what each type means.
• Benefit: Categorizing notifications would make the list of options to toggle on and off shorter and more manageable for the user.

Navigation to the Notifications Page:

• Question: How will users navigate to the notifications page?
• Suggestion: There are two potential options: either in the dropdown bell where the notifications currently are or in a dedicated section in the sidebar.
• Consideration: Easy access to the notifications settings page is crucial for user convenience and effective management.

[pandafy]

I took the following notes from our discussion on July 23, 2024 weekly meeting:

Action: User disables the global notification

• Using a single API request, disable all notifications for all organizations.
• Reflect this change in the UI using JS

Action: User overrides global settings in the specific org settings:

• This shall be allowed
• The internal code which decides whether to send a notification or not shall not take into account the global settings, only the specific settings (the code would mostly remain unaltered), the global settings would be used as a base for creating new notification settings when a user is added to an organization.

Action: Creating new notification settings

• Check the global setting of the user. If the global setting does not exist, create it with both web and email notifications enabled.
• Create organization notification setting based on the global setting of the user

Cases where new new notification settings are created:

• a new user object is created
• the user is added to a new organization

Note: Create a data migration for creating global notification settings for the existing users.

[pandafy]

Details on the current implementation of the notification settings:

The notification type defines the default value for enabling/disabling web or email notifications.

openwisp-notifications/openwisp_notifications/types.py

Lines 6 to 33 in 3b0fc9d

	NOTIFICATION_TYPES = {
	'default': {
	'level': 'info',
	'verb': 'default verb',
	'verbose_name': 'Default Type',
	'email_subject': '[{site.name}] Default Notification Subject',
	'message': (
	'Default notification with {notification.verb} and level {notification.level}'
	' by [{notification.target}]({notification.target_link})'
	),
	'message_template': 'openwisp_notifications/default_message.md',
	'email_notification': True,
	'web_notification': True,
	},
	'generic_message': {
	'level': 'info',
	'verb': 'generic verb',
	'verbose_name': 'Generic Type',
	'email_subject': '[{site.name}] Generic Notification Subject',
	'message': (
	'Generic notification with {notification.verb} and level {notification.level}'
	' by [{notification.actor}]({notification.actor_link})'
	),
	'description': '{notification.description}',
	'email_notification': False,
	'web_notification': True,
	},
	}

If the user's notification setting for web and email field are same as what is defined in the notification type, then None is stored in the database for those fields.

openwisp-notifications/openwisp_notifications/base/models.py

Lines 290 to 295 in 3b0fc9d

	def full_clean(self, *args, **kwargs):
	if self.email == self.type_config['email_notification']:
	self.email = None
	if self.web == self.type_config['web_notification']:
	self.web = None
	return super().full_clean(*args, **kwargs)

Thus, the notify_handler also queries for notificationsetting__web=None if the type has web notifications enabled by default.

openwisp-notifications/openwisp_notifications/handlers.py

Lines 85 to 87 in 3b0fc9d

	web_notification = Q(notificationsetting__web=True)
	if notification_template['web_notification']:
	web_notification |= Q(notificationsetting__web=None)

And for the same reason, the new notification settings are created with email and web field set to None.

[nemesifier]

@avocadodavinci: due to technical, time and budget constraints we cannot implement the full solution proposed by URA right now.
Our goal in this iteration is to improve the situation without drastic changes to the backend code, which would require more time than what we have a available right now.

Therefore we are focusing our effort on integrating the piece of feedback which is most compatible with our current timeline and resources.

We are confident that this iteration will make the life easier for users compared to the current situation.

Further Considerations

To further refine the proposed solution, we should consider the following questions and suggestions:

When will users first define their notification preferences?

• Question: Is this something that will be done during the initial configuration process, or is the default setting for all new configurations going to be to receive notifications?

Notifications are enabled by default and users opt-out.
There's a way to change the defaults from some configuration settings but not from UI.
We are working on a feature that allows to batch email notifications, to avoid sending too many, the first iteration is almost ready to merge.

• Consideration: Defining when and how users set their initial preferences can help streamline the notification management process and ensure users are not overwhelmed from the start.

I created a new issue for this: #293

Defining Types of Notifications:

• Suggestion: It would be valuable to better define the types of notifications. For example, there could be three categories: Warning, Info, and Error. By having these different types of notifications defined you could group them together in the dropdown settings to make them easier for the user to understand. These categories should also be explained in more detail on the notification page, clarifying what each type means.
• Benefit: Categorizing notifications would make the list of options to toggle on and off shorter and more manageable for the user.

I think this is a good idea and we could address it in future iterations.
We would also need to allow users to open a full page where they can see and filter all notifications.
That would probably make it easier to monitor all the relevant events happening in the network.

Navigation to the Notifications Page:

• Question: How will users navigate to the notifications page?
• Suggestion: There are two potential options: either in the dropdown bell where the notifications currently are or in a dedicated section in the sidebar.
• Consideration: Easy access to the notifications settings page is crucial for user convenience and effective management.

We intend to replace the "show unead only" button here:

With a button that takes to the notification preferences.

An alternative or additional option (we could do both to increase discoverability) is to add another link here, just before the "log out" link:

@avocadodavinci do you think doing both is acceptable?

Administrators will also be able to edit the notification preferences of other users.
The current notification settings in the user detail page (shown below) will be replaced with a link to the new notification preferences page.

This last option will be reserved to superusers or organization administrators.

[avocadodavinci]

@nemesifier I figured there might be some technical constraints at this time, let me know when you’ve implemented the short term improvements and I can take another look.

As to your question about navigating to the notifications page, adding it to multiple locations can increase cognitive load and clutter, potentially confusing users.

I would opt to Have it appear only in the notification drop-down, this is the most intuitive option and it aligns with the user’s expectations.

[nemesifier]

@nemesifier I figured there might be some technical constraints at this time, let me know when you’ve implemented the short term improvements and I can take another look.

As to your question about navigating to the notifications page, adding it to multiple locations can increase cognitive load and clutter, potentially confusing users.

I would opt to Have it appear only in the notification drop-down, this is the most intuitive option and it aligns with the user’s expectations.

Ok, thanks 👍