Skip to content

[3.0] Say whether the label being put on a PM is going on or coming off - #9462

Open
albertlast wants to merge 1 commit into
SimpleMachines:release-3.0from
albertlast:3.0/pm-label-dropdown-prefix
Open

[3.0] Say whether the label being put on a PM is going on or coming off#9462
albertlast wants to merge 1 commit into
SimpleMachines:release-3.0from
albertlast:3.0/pm-label-dropdown-prefix

Conversation

@albertlast

Copy link
Copy Markdown
Collaborator

Description

The drop down beside each message in the inbox offers two lists of labels — the ones that can be applied, and the ones that can be taken off — and gave both of them a bare label ID as their value:

// Are there any labels which can be added to this?
<option value="', $label['id'], '">', $label['name'], '</option>
...
// ... and are there any that can be removed?
<option value="', $label['id'], '">&nbsp;', $label['name'], '</option>

Nothing downstream can tell those two apart, and PersonalMessage::applyActions() does not try. It reads an add_ or rem_ prefix and skips anything else:

elseif (str_starts_with($action, 'add_')) {
    $type = 'add';
    ...
} elseif (str_starts_with($action, 'rem_')) {
    $type = 'rem';
    ...
}

if (isset($type) && \in_array($type, ['add', 'rem']) && ...) {

So picking a label from that drop down did nothing at all. smf_pm_labeled_messages stays empty, no error is logged, and the page reloads looking exactly as it did.

The values are written this way because SMF 2.1 read a bare value as "toggle this label" — it had an else { $type = 'unk'; } branch, and further down, if (array_key_exists(...) && $type !== 'add') unset(...); elseif ($type !== 'rem') .... 3.0 dropped that branch and kept the markup, which is why the drop down looks fine and does nothing.

The template knows perfectly well which of the two lists it is drawing, so it says so. That is also exactly what loadLabelChoices() in this same file builds for the whole-folder drop down ("add_" + i, "rem_" + i), which has been the only working way to label a PM.

Verified the round trip on the inbox:

step drop down offers pm_labeled_messages
start add_2 Alpha, add_3 Beta empty
pick add_2 add_3 Beta, rem_-1 Inbox, rem_2 Alpha 2-1
pick rem_2 add_2 Alpha, add_3 Beta empty

Nothing new in the error log either way.

Issues References (Fixes|Related|Closes)

n/a

The drop down beside each message in the inbox offers two lists of labels
- the ones that can be applied and the ones that can be taken off - and
gave both of them a bare label ID as their value. Nothing downstream can
tell those apart, and applyActions() does not try: it reads an "add_" or
"rem_" prefix and ignores anything else, so choosing a label did nothing
at all.

SMF 2.1 read a bare value as "toggle this label", which is why the values
were written this way. 3.0 dropped that branch and kept the markup.

The template knows perfectly well which list it is drawing, so it says so.
That is the same value loadLabelChoices() builds for the drop down that
acts on the whole folder, which has been the only working way to label a
PM.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants