MyVideoGameList/myvideogamelist.com

Watch

Show the total count of banned users #1013

New issue

Closed

opened 2026-11-05 11:08:38 -06:00 by Codex · 2 comments

Codex commented

2026-11-05 11:08:38 -06:00

Member

The banned-users administration page should expose the size of the current banned-user collection in its card header.

The count belongs to the page data supplied by the existing admin route/controller and should be rendered by the existing Blade view.],

scope　:[

Scope

Update the banned-users page data flow to provide the total number of banned users.
Render that total in the right-hand card header on /admin/users/banned.
Add focused feature coverage for the displayed count.

Acceptance Criteria

The /admin/users/banned card header displays the total number of banned users.
The displayed value matches the number of banned users returned by the page's existing query.
The count is zero when no banned users exist.
Existing banned-user listing and administrative actions continue to work unchanged.

Test Coverage Required

Add a feature test covering a banned-user dataset and asserting its total appears on the banned-users page.
Add a feature test covering the empty banned-user state and asserting a zero count.

Progress Checklist

Locate the existing banned-users route/controller and Blade view.
Expose the banned-user total alongside the existing page data.
Render the total in the right-hand card header.
Add and run focused feature coverage for populated and empty states.

The banned-users administration page should expose the size of the current banned-user collection in its card header. The count belongs to the page data supplied by the existing admin route/controller and should be rendered by the existing Blade view.], scope　:[ ## Scope - Update the banned-users page data flow to provide the total number of banned users. - Render that total in the right-hand card header on `/admin/users/banned`. - Add focused feature coverage for the displayed count. ## Acceptance Criteria - The `/admin/users/banned` card header displays the total number of banned users. - The displayed value matches the number of banned users returned by the page's existing query. - The count is zero when no banned users exist. - Existing banned-user listing and administrative actions continue to work unchanged. ## Test Coverage Required - Add a feature test covering a banned-user dataset and asserting its total appears on the banned-users page. - Add a feature test covering the empty banned-user state and asserting a zero count. ## Progress Checklist - [x] Locate the existing banned-users route/controller and Blade view. - [x] Expose the banned-user total alongside the existing page data. - [x] Render the total in the right-hand card header. - [x] Add and run focused feature coverage for populated and empty states.

Codex added the

needs codex review

label

2026-11-05 11:08:38 -06:00

Codex changed title from ~~Show Total Count of Banned Users~~ to Show the total count of banned users

2026-11-05 11:09:00 -06:00

Codex added

component: admin dashboard

component: security

component: tests

and removed

needs codex review

labels

2026-11-05 11:09:00 -06:00

jimmyb added this to the New Features - Part 1 project

2026-11-05 16:08:17 -06:00

Codex added

and removed

labels

2026-11-06 15:50:00 -06:00

Codex self-assigned this

2026-11-06 15:50:00 -06:00

Codex referenced this issue from a pull request that will close it,

2026-11-06 16:01:14 -06:00

Show the total banned user count #1021

jimmyb closed this issue

2026-11-06 17:29:28 -06:00

Codex commented

2026-11-06 17:31:48 -06:00

Author

Member

Implemented in merged PR #1021 (master revision 99451d50). The banned-users card header now displays Total banned users: N, using the existing paginator total without another database query. The total spans all pages, includes flag-only and role-only bans and soft-deleted banned accounts, and counts accounts with both markers only once. Empty results show zero. Existing listing, pagination, edit links, authorization, and ban actions are preserved.

Validation: 32 feature tests passed with 165 assertions, covering populated and empty headers, pagination, user search, and ban actions; Pint, PHPStan, and diff checks passed. All progress checklist items are complete. No schema, dependency, or frontend asset changes are required. Deployment to development and production follows separately.

Implemented in merged PR #1021 (master revision 99451d50). The banned-users card header now displays `Total banned users: N`, using the existing paginator total without another database query. The total spans all pages, includes flag-only and role-only bans and soft-deleted banned accounts, and counts accounts with both markers only once. Empty results show zero. Existing listing, pagination, edit links, authorization, and ban actions are preserved. Validation: 32 feature tests passed with 165 assertions, covering populated and empty headers, pagination, user search, and ban actions; Pint, PHPStan, and diff checks passed. All progress checklist items are complete. No schema, dependency, or frontend asset changes are required. Deployment to development and production follows separately.

Codex added

and removed

labels

2026-11-06 17:31:49 -06:00

Codex commented

2026-11-06 17:35:52 -06:00

Author

Member

Deployed merged master revision 99451d50b3aafe66ffbc1bd761a2bbda98a7e5bc (PR #1021) to development and production. Both release manifests now end in +pr1021-99451d50, and SHA-256 checks confirm the controller and banned-users Blade template match the merged source. Read-only live checks verified that the controller total matches the banned-user query and that the count renders inside the card header; Blade compilation and view-cache rebuilds passed. Unrelated application files, assets, and configuration were checksum-guarded. No migrations, dependency updates, or account/domain-data writes were performed.

Development verification initially triggered automatic rollbacks because the smoke harness blocked a routine shared-header cache write and then encountered a stale compiled view. The harness now uses in-memory cache and rebuilds compiled views before rendering; the same corrected procedure passed on both environments. No application-code changes were needed.

Rollback backups retained:

Development: /home/mvgldev/deploy-backups/pr1021-99451d50-j28ztgia
Production: /home/mvgl/deploy-backups/pr1021-99451d50-691s0uvw

Each deployment account retains ~/deploy-staging/pr1021-99451d50/deploy.py. To restore, run it as the matching account with ~/bin on PATH and --rollback <backup-path>; it restores the prior controller, template, and release manifest and rebuilds the view cache.

HTTPS smoke checks passed: development and production home pages return 200, production login returns 200, and unauthenticated requests to /admin/users/banned redirect to each environment's login page. PHP-FPM has OPcache timestamp validation enabled with a two-second revalidation interval, so the new PHP code is picked up automatically; no manual reload was needed.

Deployed merged master revision `99451d50b3aafe66ffbc1bd761a2bbda98a7e5bc` (PR #1021) to development and production. Both release manifests now end in `+pr1021-99451d50`, and SHA-256 checks confirm the controller and banned-users Blade template match the merged source. Read-only live checks verified that the controller total matches the banned-user query and that the count renders inside the card header; Blade compilation and view-cache rebuilds passed. Unrelated application files, assets, and configuration were checksum-guarded. No migrations, dependency updates, or account/domain-data writes were performed. Development verification initially triggered automatic rollbacks because the smoke harness blocked a routine shared-header cache write and then encountered a stale compiled view. The harness now uses in-memory cache and rebuilds compiled views before rendering; the same corrected procedure passed on both environments. No application-code changes were needed. Rollback backups retained: - Development: `/home/mvgldev/deploy-backups/pr1021-99451d50-j28ztgia` - Production: `/home/mvgl/deploy-backups/pr1021-99451d50-691s0uvw` Each deployment account retains `~/deploy-staging/pr1021-99451d50/deploy.py`. To restore, run it as the matching account with `~/bin` on PATH and `--rollback <backup-path>`; it restores the prior controller, template, and release manifest and rebuilds the view cache. HTTPS smoke checks passed: development and production home pages return 200, production login returns 200, and unauthenticated requests to `/admin/users/banned` redirect to each environment's login page. PHP-FPM has OPcache timestamp validation enabled with a two-second revalidation interval, so the new PHP code is picked up automatically; no manual reload was needed.

Sign in to join this conversation.

No labels

component: admin dashboard

component: backend

component: billing

component: content management

component: faqs

component: game genres

component: game lists

component: game reviews

component: game search

component: games

component: internal notifications

component: platforms

component: security

component: tests

component: user api

component: user badges

component: user blogs

component: user consoles

component: user favorites

component: user friends

component: user notifications

component: user profiles

component: user site notifications

component: user wishlists

component: web design

security-hotspot

source: sonarqube

awaiting feedback

needs codex review

needs investigation

type: documentation

type: improvement

type: regression

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

MyVideoGameList/myvideogamelist.com#1013

No description provided.