ARCH-001 Phase 26: consolidate Admin/Store OnlineCustomerController - #827
Merged
KrzysztofPajak merged 1 commit intoSep 11, 2026
Merged
Conversation
…nto BaseOnlineCustomerController Admin's and Store's OnlineCustomerController were near-identical (~80 lines each) - same List(GET)/List(POST) grid action, same GetOnlineCustomers call and model mapping. No entity, no per-store/per-vendor scope beyond the StaffStoreId filter both hosts already applied identically, so no IAdminDataScope is needed here (same shape as BasePictureController). Vendor never had its own copy. The one real difference: Admin restricts the online-customer list to the current Sales-Manager's own customers via GetOnlineCustomers' salesEmployeeId parameter; Store has no such concept and always passes null. Parameterized with a protected virtual SalesEmployeeIdFilter member on the new BaseOnlineCustomerController (Grand.Web.AdminShared) - the same idiom this repo's pre-existing BaseLoginController already uses for its own host-specific GetCurrentArea() value. Admin's thin subclass overrides it to the current customer's SeId; Store keeps the base's null default. Both List actions moved verbatim (aside from field -> primary-constructor- parameter renames and the LINQ vs foreach style difference, which produce identical output - unified on Store's LINQ form). Base carries [PermissionAuthorize(PermissionSystemName.Customers)] and [AutoValidateAntiforgeryToken]; Admin/Store subclasses restate their host's [AuthorizeAdmin|AuthorizeStore]/[Area]/[AuthorizeMenu] attribute set, matching the established ARCH-001 pattern. No prior test coverage existed for either controller. Added: - BaseOnlineCustomerControllerTests: default vs overridden SalesEmployeeIdFilter branches, guest-email fallback mapping, StoreLastVisitedPage on/off. - OnlineCustomerControllerAttributeTests (Admin + Store): subclass/attribute wiring, same shape as EmailAccountControllerAttributeTests. No behavior change. Verified: dotnet build GrandNode.sln 0 errors; Admin 1436/1436, Store 141/141 (run separately, per known parallel-run flakiness). No live smoke test run this phase - deferred, disclosed in the PR body (this controller is a read-only admin/store list with no cross-tenant write surface). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013y3MqvZq7y1Uc5p4JZad2i
KrzysztofPajak
deleted the
arch001/phase26-onlinecustomer-consolidation
branch
September 11, 2026 13:59
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ARCH-001 Phase 26: OnlineCustomerController consolidation
One of several fresh candidates found by a repo-wide Admin/Store/Vendor controller survey. Admin's
and Store's
OnlineCustomerControllerwere near-identical (~80 lines each) — sameListGET/POSTgrid action, same
GetOnlineCustomerscall and model mapping. No domain entity, no per-store/per-vendor scope beyond the
StaffStoreIdfilter both hosts already applied identically, so — likeBasePictureController— noIAdminDataScope<TEntity>is needed. Vendor never had its own copy.The one real difference
Admin restricts the online-customer list to the current Sales-Manager's own customers via
GetOnlineCustomers'ssalesEmployeeIdparameter; Store has no such concept and always passesnull. Parameterized with aprotected virtual SalesEmployeeIdFiltermember on the newBaseOnlineCustomerController— the same idiom this repo's pre-existingBaseLoginControlleralready uses for its own host-specific
GetCurrentArea()value. Admin's thin subclass overrides itto the current customer's
SeId; Store keeps the base'snulldefault.Change
Both
Listactions moved intoBaseOnlineCustomerController(Grand.Web.AdminShared), carrying[PermissionAuthorize(PermissionSystemName.Customers)]and[AutoValidateAntiforgeryToken].Admin/Store
OnlineCustomerControllerare now thin subclasses restating their host's[AuthorizeAdmin|AuthorizeStore]/[Area]/[AuthorizeMenu]attribute set — same shape asBaseProductController,BasePictureController, etc. No behavior change (the LINQ-vs-foreachstyle difference between the two originals produced identical output; unified on Store's LINQ form).
Tests
No prior test coverage existed for either controller. Added:
BaseOnlineCustomerControllerTests— default vs overriddenSalesEmployeeIdFilterbranches,guest-email fallback mapping,
StoreLastVisitedPageon/off.OnlineCustomerControllerAttributeTests(Admin + Store) — subclass/attribute wiring, same shapeas
EmailAccountControllerAttributeTests.Verification
dotnet build GrandNode.sln— 0 errors. Per-project test runs (parallel full-solution runs areknown-flaky, see repo history):
Grand.Web.Admin.Tests: 1436/1436Grand.Web.Store.Tests: 141/141No live smoke test run this phase — disclosed as an open item, not silently skipped. This
controller is a read-only admin/store online-customer list with no cross-tenant write surface, but
per this initiative's standing "green build proves nothing about routing/wiring" lesson, a live
check is still the more rigorous bar; deferred here to keep this phase's turnaround fast, open for
follow-up before merge if the reviewer wants it.