fix(qt): keep PoSe score visible when hiding banned masternodes

[thepastaclaw]

PR description

Summary

• Keep the Masternodes tab PoSe Score column visible when "Hide banned" is
  checked.
• Continue filtering banned masternodes via the existing proxy filter.

Closes #7286.

Validation

• git diff --check
• Pre-PR review gate: ship
• Not run: full build / GUI smoke test; no build directory was available in
  this worktree.

[thepastaclaw]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[github-actions]

✅ No Merge Conflicts Detected

This PR currently has no conflicts with other open PRs.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 5ace1b09-560e-4295-bad1-045e3bb24a8f

📥 Commits

Reviewing files that changed from the base of the PR and between 7e524b1 and 1d9e004.

📒 Files selected for processing (1)

• src/qt/masternodelist.cpp

💤 Files with no reviewable changes (1)

• src/qt/masternodelist.cpp

---

Walkthrough

The "Hide banned" checkbox handler in the masternode list was modified to remove the logic that hid the POSE table column. The handler now focuses solely on filtering banned rows through the proxy model by calling setHideBanned(...), invalidating the filter, recalculating row counts, and persisting the user preference.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: keeping the PoSe Score column visible when hiding banned masternodes, which directly addresses the changeset.
Description check	✅ Passed	The description clearly explains the fix and its purpose: keeping the PoSe Score column visible while filtering banned masternodes through the proxy filter.
Linked Issues check	✅ Passed	The code changes directly address issue #7286 by removing the column-hiding behavior from the 'Hide banned' checkbox while maintaining filtering via the proxy model.
Out of Scope Changes check	✅ Passed	The changes are narrowly focused on the 'Hide banned' checkbox handler, removing only the column-hiding logic while preserving filtering behavior, with no unrelated modifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 7/8 reviews remaining, refill in 7 minutes and 30 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[thepastaclaw]

✅ Review complete (commit 1d9e004)

[thepastaclaw]

Code Review

Minimal one-line fix that correctly decouples the POSE column visibility from the 'Hide banned' filter. The previous behavior was asymmetric (toggling on hid the column but toggling off never restored it). The proxy filter still excludes banned rows. Both reviewers converged on a single test-coverage suggestion; no blocking issues.

Reviewed commit: 1d9e004

💬 1 nitpick(s)

1 additional finding

💬 nitpick: No Qt test covers the Hide Banned / PoSe column behavior

src/qt/masternodelist.cpp (lines 291-300)

The fix lives entirely in MasternodeList::on_checkBoxHideBanned_stateChanged, but no test under src/qt/test/ exercises MasternodeList. The Qt test harness already exists in src/qt/test/test_main.cpp, so a focused test that toggles checkBoxHideBanned and asserts both the filtered row count and that tableViewMasternodes->isColumnHidden(MasternodeModel::POSE) remains false would prevent the same regression from reappearing. Not blocking — the fix is small and correct — but the original bug slipped through precisely because there was no automated coverage of this surface.