Why not just rewrite the current page that already covers existing subscriptions to boards/topics?
[Plugin] Re: Notifications system (1.0)
« Reply #165, on June 2nd, 2013, 10:11 PM »
Why not just rewrite the current page that already covers existing subscriptions to boards/topics?
![]() | The way it's meant to be |
I got no problem with that provided that the UI is usable :)
SELECT m.id_member, m.real_name, m.unread_notifications, (SELECT COUNT(id_notification) FROM notifications AS n WHERE n.id_member = m.id_member AND n.unread != 0) AS real_count FROM members AS m WHERE m.unread_notifications > 0SELECT COUNT(id_notification) AS co, id_notification, id_member, notifier, id_object, SUBSTRING_INDEX(data, 's:2:"id";s:', -1) AS truc FROM notifications WHERE id_member_from=0 GROUP BY truc ORDER BY co DESCI probably should mark items as read as soon as they're previewed, though.
Dunno what's the point in keeping the member ID in the data field, though...! ;)
Stick a fork in it SMF | ![]() |
What do you mean, exactly..? :^^;:
I've left a few notifications pending for a bit, partly to prove emailing them works and partly to see what happens when a user accrues a lot of notifications (11 unread so far), and the sense I'm getting is for a "mark all read" button.
Thoughts?
I have a solution for the whole local mailserver thing... it's called 'not worrying about it but making sure I have mail queue enabled'... because then I can see what entered the queue.