Skip to content

[3.0] Save the notification preference the member asked for - #9477

Open
albertlast wants to merge 1 commit into
SimpleMachines:release-3.0from
albertlast:3.0/notify-pref-save
Open

[3.0] Save the notification preference the member asked for#9477
albertlast wants to merge 1 commit into
SimpleMachines:release-3.0from
albertlast:3.0/notify-pref-save

Conversation

@albertlast

Copy link
Copy Markdown
Collaborator

Description

Topic and board notifications do not work on release-3.0. Three separate faults, all on the same path.

1. NotifyTopic::changePref() passes a single row where a list is required.

Db::insert() needs $data to be an array of rows; with $backward_compatibility off (the default) anything else is Invalid data structure sent to the database. and a critical row in the error log. Notify::changeBoardTopicPref() a few lines away wraps its row correctly - this one does not.

?action=notifytopic;topic=1.0;sa=on  ->  500, "Invalid data structure sent to the database.<br>Function: changePref"

2. sa=off picks a mode nothing handles.

saToMode() maps off to -1, and -1 is MODE_NO_ALERT, for which setAlertPref() has no case. $alert_pref is a typed property with no default, so the next line to read it throws:

Typed property SMF\Actions\Notify::$alert_pref must not be accessed before initialization

That is the UNSUBSCRIBELINK at the foot of every notification email (Tasks/CreatePost_Notify.php), and the No link on the notification confirmation page, for both topics and boards.

In 2.1 the value -1 meant "turn off email notifications while leaving the alert pref unchanged" - which 3.0 renamed to MODE_NO_EMAIL (-2) when it split the constant in two, without updating saToMode(). Pointing sa=off at MODE_NO_EMAIL restores 2.1's behaviour exactly.

3. Any unknown mode did the same.

$this->mode is (int) $_GET['mode'], so ?mode=99 was also a fatal. The switch now has a default, and MODE_NO_ALERT gets the handling its name describes - the mirror of the MODE_NO_EMAIL case.

How to test

?action=notifytopic;topic=1.0;mode=3;<session>   subscribe
?action=notifytopic;topic=1.0;sa=off;<session>   the email unsubscribe link
?action=notifyboard;board=1.0;sa=off;<session>

Before: 500 on all three, with the errors above in smf_log_errors. After: all redirect, the log stays empty, and smf_user_alerts_prefs shows board_notify_1 going 3 → 1 on sa=off - email bit cleared, alert bit kept, as in 2.1.

Issues References (Fixes|Related|Closes)

Found while sweeping the topic display for the #7933 split.

Three things stopped a topic or board notification from being set.

Db::insert() wants a list of rows, and changePref() handed it a single
one, so turning notification on for a topic answered "Invalid data
structure sent to the database" and logged a critical error.

sa=off maps to mode -1, which is MODE_NO_ALERT, and setAlertPref() has no
case for it. $alert_pref is a typed property with no default, so reading
it threw - the unsubscribe link at the foot of every notification email
was a fatal error, on topics and on boards. 2.1's -1 is what 3.0 calls
MODE_NO_EMAIL, so point sa=off at that constant and the link means what it
says again.

Any other value of mode did the same thing, since mode comes from the
query string. Give the switch a default, and give MODE_NO_ALERT the
handling its name describes.

Signed-off-by: Mathias Papenbrock <mathiaspapealbert@hotmail.com>
Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
@albertlast albertlast mentioned this pull request Aug 9, 2026
@jdarwood007 jdarwood007 added this to the 3.0 Alpha 6 milestone Aug 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants