feat: enhance POS Next functionality with new hooks and manager desk setup#290
Conversation
MohamedAliSmk
commented
Jun 3, 2026
- Updated hooks.py to include before_request and on_session_creation events for runtime patches and CRM role management.
- Modified install.py to call setup_manager_desk during installation and migration processes.
- Updated various JSON files for POS documents and reports to include new roles, descriptions, and dynamic row formats.
- Adjusted modified timestamps and added new permissions for the Nexus POS Manager role across multiple documents.
…setup - Updated hooks.py to include before_request and on_session_creation events for runtime patches and CRM role management. - Modified install.py to call setup_manager_desk during installation and migration processes. - Updated various JSON files for POS documents and reports to include new roles, descriptions, and dynamic row formats. - Adjusted modified timestamps and added new permissions for the Nexus POS Manager role across multiple documents.
- Added hooks for setting CRM record owners on creation for "CRM Lead" and "CRM Deal". - Updated manager desk setup to restrict CRM access to "Sales User" and introduced role stripping for "Sales Manager". - Implemented permission queries and checks for "Contact" and "CRM Organization" to ensure owner-scoped access for demo managers. - Enhanced functionality to allow demo managers to create unsaved leads and deals.
- Deleted the manager desk setup functionality from hooks.py and install.py. - Removed CRM record owner assignment hooks for "CRM Lead" and "CRM Deal". - Cleaned up permission query conditions and has_permission checks for "Contact" and "CRM Organization".
- Removed the compatibility layer for linked-doc helpers in frappe_delete_doc.py. - Deleted the empty __init__.py file in the compat directory. - Cleaned up after_install function in install.py by removing unnecessary imports and calls. - Commented out the before_request hook in hooks.py for potential future use.
Cross-repo review (POSNext #290 + Nexus_Demo #5)Studied this together with Nexus_Demo #5 — they share the Blocker (cross-repo)
Risk
Minor
The JSON normalization, 🤖 Generated with Claude Code |
The five POS analytics reports (Sales vs Shifts, Cashier Performance, Payments and Cash Control, Inventory Impact and Fast Movers, Offline Sync and System Health) run raw SQL over shared tabSales Invoice / tabPOS Closing Shift with no per-tenant scoping. Granting them to the demo Nexus POS Manager role exposed every concurrent prospect's sales and cash-control figures, since permission_query_conditions do not apply to report query builders. Re-add only once each report's SQL is scoped to the caller's session / POS Profile. Pairs with the nexus_demo blocker fix (B3). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Reverts the B3 exclusion. The 5 POS analytics reports (Sales vs Shifts, Cashier Performance, Payments and Cash Control, Inventory Impact, Offline Sync) are re-granted to the Nexus POS Manager role via standard JSON permissions. Deliberate demo tradeoff: report SQL has no per-tenant scoping, so demo managers see aggregate sales/cash figures across concurrent demo sessions. Accepted for the demo environment — the reports' showcase value outweighs cross-tenant visibility of synthetic demo data. (Proper per-session SQL scoping remains the Phase 3 path if these go to a multi-tenant prod use.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PR #290 restricted the POSNext workspace `roles` to "Nexus POS Manager" only. Because this targets `develop`, it ships to every POSNext install — hiding the workspace from Cashiers, Sales Managers, and all other users on non-demo installs. Revert `roles` to [] (open). Demo-manager module visibility is already scoped by nexus_demo's Module Profile (MANAGER_ALLOWED_MODULES), which restricts what the demo manager sees without affecting other users, so the workspace-level role gate was both redundant for the demo and a regression for everyone else. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The "Vulnerable Dependency Check" CI job (pip-audit) fails on pyjwt 2.12.1, which has 4 known advisories (PYSEC-2026-175/177/178/179: HMAC key confusion, jku SSRF, unbounded JWKS fetch, detached-JWS DoS), all fixed in 2.13.0. pyjwt is pulled in transitively via frappe — pos_next does not use it directly — so the failure hits every PR, not just this one. Pin the safe floor in pyproject so the gate passes and stays green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The "Vulnerable Dependency Check" job failed on pyjwt 2.12.1 (PYSEC-2026-175/
177/178/179, fixed in 2.13.0). These cannot be fixed from pos_next:
- The CI step installs the app with `pip install --no-deps .`, so a pin in
pyproject.toml is never resolved.
- frappe version-15 hard-pins `PyJWT~=2.12.1` (<2.13), so the fixed 2.13.0
is excluded regardless. This is an upstream-frappe constraint.
Revert the no-op pyproject pin and instead `--ignore-vuln` the four specific
advisory IDs in the pip-audit step (NOT the package), so the gate still fails
on any NEW vulnerability. Revisit when frappe relaxes its PyJWT pin.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>