[buddypress-trac] [BuddyPress Trac] #6712: Screen notifications settings page

[buddypress-trac]

#6712: Screen notifications settings page
-------------------------------------+-----------------------------
 Reporter:  r-a-y                    |       Owner:
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Toolbar & Notifications  |     Version:  1.9
 Severity:  normal                   |  Resolution:
 Keywords:  ui-feedback              |
-------------------------------------+-----------------------------

Comment (by r-a-y):

 Thanks for the mockups, @mercime!

 After looking into this some more, the problem I'm seeing is there are
 some notifications that are applicable only to email and some that are
 only applicable to screen (or web) notifications.


 My remarks in comment:20 still stand:

 >  If we believe that there should be just one Notification settings page
 that encompasses Emails, Screen Notifications (and potentially more), we
 should only add this functionality once we figure out how to handle
 outputting and saving existing Email settings and figuring out a system
 that would work for third-party components as well.

 > #6932 actually proposes a schema to handle registering email
 notification metakeys, but that would only work for core emails. Existing
 plugins using the 'bp_notification_settings' <table> hook would not be
 displayed. I'm not sure if it is possible to maintain backward
 compatibility.

 ----

 That being said, I've implemented this checkbox interface in `04.patch`.

 Here's what I did:

 - To implement this page, I object buffered the entire
 `'bp_notification_settings'` hook and did some DOM parsing to determine
 what the notification options are ''(insert :poo: emoji here!)''.  The
 positives of this is older plugins that are using the
 `'bp_notification_settings'` hook will work.  The negative is some plugins
 are abusing this hook to add additional information that is not a table.
 I also haven't added a new API for components / plugins to register
 separate notification sections yet.  This is obviously more of a proof-of-
 concept at the moment, rather than a final iteration.

 - Had to map existing email user meta keys to those used by the
 Notification component's `'component_action'` DB column.  The better way
 here is to somehow re-use the email schema outlined in #6932 -
 [https://buddypress.trac.wordpress.org/browser/tags/2.6.2/src/bp-core/bp-
 core-functions.php#L3228 bp_email_get_type_schema()], but that is mostly
 tied to the email post type... also plugins cannot add their own schema to
 that function.

 - Introduces a way for plugins to register a new notification type.  For
 example, the Notifications component registers the `screen` notification
 type in `bp-notification-settings.php`.

 - At the moment, if a plugin is adding screen notifications and they want
 a user to have the ability to disable it, plugins will have to register
 their mapped email meta key to their notification `component_action`.  See
 `bp_notifications_get_mapped_notification_actions()`.  This is all because
 I'm piggybacking off the existing email meta keys.  This will probably
 need to be revamped.

 - Unlike how each user email notification setting is saved individually as
 a separate user meta entry, the patch only saves ''disabled'' screen
 notification data into one user meta key -
 `screen_notifications_disabled`.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6712#comment:30>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac