# Pasco Digital New

> Pasco Digital New (iPhone/iPad app by Devender Yadav.)

- Source: https://appshunter.io/ios/app/pasco-digital-new/id6759968988 (this page in markdown: same URL + `.md`)
- Developer: [Devender Yadav](https://appshunter.io/developer/1863625180)
- Category: Business, Productivity
- Price: Free
- Age rating: 4+
- Requires: iOS 15.1 · 37 MB
- Languages: American English
- Released: 2026-03-25
- Data updated: 2026-08-20
- User reviews in markdown: https://appshunter.io/ios/app/pasco-digital-new/id6759968988/reviews.md

## What is Pasco Digital New?

Pasco is a comprehensive automotive dealership management platform that streamlines vehicle sales, customer management, accessories inventory, and daily operations — all from your mobile device.

Key Features:

• Customer Management — Track customer journeys from enquiry to final delivery, manage documents, feedback, and approvals.

• Vehicle Operations — Manage vehicle models, variants, pricing, Pre-Delivery Inspections (PDI), stock yard movements, and service entries.

• Accessories & Inventory — Full inventory lifecycle including stock receipts, transfers, adjustments, sales orders, returns, warehouse management, and real-time stock tracking.

• Sales & Quotations — Create and manage quotations, track leads, schedule test drives, and process replacement handovers.

• Staff Attendance — GPS-based check-in/check-out, attendance history, location-verified working hours, and calendar view.

• Reports & Analytics — Performance reports, sales summaries, stock movement analysis, inventory valuation, and warehouse utilization.

• Role-Based Access — Fine-grained permissions ensure every user sees only what they need.

• Secure Authentication — Biometric login (Face ID / Touch ID), encrypted credential storage, and session management.

Designed for automotive dealerships to manage their end-to-end operations efficiently.


## Version history (last 5 releases)

### 2.5.18 — 2026-08-18

1. Branch Admin could create a user and then lose it — fixed
This was the single biggest functional fix in the window, and it took three commits.

The dead end: V685 gave Branch Admin users:view:branch, which narrows the Users grid to people assigned to the admin's own branches. But the create-user flow never assigns a branch — branch assignment is a separate step you reach by clicking the row in the grid. Because branch_staff is LEFT JOINed and NULL IN (...) evaluates to NULL, the brand-new user vanished from the grid the instant it was saved. The Branch Admin could never reach the modal that would have made it visible. The account was stranded until a full ADMIN stepped in.

users.created_by added (V735) — stamped by UserCreationService, which had always received the creator's id as an argument and simply thrown it away because there was nowhere to put it. All four scope query sites now also match bs.branch_id IS NULL AND u.created_by = :currentUserId, so you keep sight of the branch-less users you created — and only those. The moment a branch is assigned, the row falls back under the normal branch rule. Deliberately not backfilled: there's no historical record of who created existing accounts, and guessing would hand accounts to the wrong branch admin. Pre-existing stranded users stay ADMIN-only to clear. The endpoint guard (assertWithinBranchScope) got the same allowance, otherwise the row would list but 403 on open. FK is ON DELETE SET NULL, with a partial index on the non-NULL rows.

"Manage Branches" modal offered branches it couldn't use — the "Add Branches" tab listed every branch in the organisation to a branch-scoped admin, and any choice outside their own branches failed the submit with "You do not have permission to access this resource." The read side and the write guard had drifted apart. Both now go through one method, resolveBranchStaffScope. The "Current Branches" tab gained an opt-in callerScoped flag so it only lists branches whose Remove action can actually succeed. Opt-in on purpose — the mobile driver screens use the same endpoint just to display a driver's branches, and scoping it by default would silently blank out branches outside the viewer's scope.

"Manage Roles" / "Manage Groups" always failed for Branch Admin (V737) — both buttons render on users:manage_roles / users:manage_groups, which Branch Admin holds, but the endpoints behind them are gated on roles:assign_users / groups:assign_users, which it did not. Guaranteed dead end, every time. The grant ships with three guard fixes that had to land with it, because the grant would not have been safe alone:

GroupController never applied assertTargetNotProtected — so groups:assign_users alone would have let someone re-group an ADMIN account by posting its id directly. Added to all three group user-assignment endpoints.
Neither RoleController nor GroupController applied assertProfileBranchScope — the "only users in my branches" property was enforced purely by which rows the grid lists, which is a frontend constraint, not a security boundary. Added to both.
/roles/dropdown/for-user now hides protected roles from non-administrators, so the modal stops offering the four roles the guard would refuse anyway.
Net reach: a Branch Admin can assign any of the 64 non-protected roles, and any group, to ordinary users in its own branches. It cannot mint an ADMIN or another Branch Admin.

Profile page header stuck on "Loading…" forever — profile/page.tsx gated the "viewing someone else's profile" data fetch and all nine admin section headers on isAdmin. A Branch Admin holds user_profile:view_all but not admin:access, so the header never resolved a name, employee id or role. All eleven checks swapped to canViewProfile.

### 2.5.16 — 2026-08-14

1. Dashboard — this was the big one
Roughly a third of the release. The dashboard went from "widgets that mostly ignored what you filtered and showed you data you shouldn't see" to something that actually respects filters and permissions.

Widgets now obey the date filter you picked. Before, most widget queries were unbounded — you'd change the date range at the top and half the tiles wouldn't move. Every provider (Dealer, Services, Bodyshop, Accessories, Insurance, Platform) now takes a date window. We had to split widgets into two kinds to do this honestly: FLOW metrics (leads created, deliveries done — these get date-bounded) and STOCK metrics (vehicles currently in yard, stock on hand — these are a snapshot of "right now" and deliberately ignore the date range, because "vehicles in stock last Tuesday" isn't a thing we can reconstruct). Each method now carries a comment saying which it is, so nobody "fixes" a stock widget into a flow widget later. A new DashboardWindowResolver decides the window once and hands the same one to every widget, so tiles can't silently disagree about what "this month" means.

Widgets now obey branch filtering too. Every provider takes the caller's branch list. Previously a user with two branches could see company-wide numbers in a tile while the underlying page showed only their two branches.

And they obey who-created / who-is-assigned scoping. New DashboardWidgetScopeResolver works out, per widget, whether you get everything, only your branches, or only rows you created or are assigned. It applies to dealer leads, customers, insurance leads, bodyshop conversions and quotations. The rule it enforces: a widget can never show you more than the page it came from would. Two migrations (V727, V731) go back and revoke widget tiers that weren't backed by real page access — so some users will see fewer widgets after this deploy, which is the point.

Dashboard permissions were rebuilt. The Dealer, Sales and Inventory tabs were all sharing one permission (dashboard:dealer:view), so giving somebody the Dealer tab for PDI metrics also handed them revenue and inventory-valuation dashboards. V732 splits them into three separately grantable permissions and — deliberately — grants all three to everyone who held the old one, so nothing changes on deploy day. Who should keep each tab is a client decision, so that lives in the PASCO client migrations (V910203–V910207), which rescope the Dealer, Services/Bodyshop, Accessories, Insurance and Platform tabs per role and rebuild the default layouts. V729 also went back and gave dashboard:view to every active role, because a batch of roles could reach the menu but got a blank page.

Click a KPI tile and you land on the filtered page. KPI cards now support drill-down: clicking through to Login History or Users pre-applies the filter the tile was counting. Both those pages learned to read filters from the URL. Same behaviour ported to the mobile KPI widget.

Empty widgets now look the same everywhere. There were about four different "no data" treatments across charts and widgets. One shared WidgetEmptyState / ChartEmpty component now, used by funnel, treemap, base charts and every widget type, on web and mobile.

### 2.5.13 — 2026-08-09

Brand-new: User Activity Tracking (Administration → Permissions → User Activity)
The biggest new platform feature. Two tabs on one page:
* Activity History — an append-only log of what a tracked user actually did. Every write on any module controller is captured server-side, and every genuine browser navigation is captured client-side (deliberately client-reported, because the server cannot tell a page refresh from a real navigation). Each row keeps the action, module, entity, route, HTTP method, success/failure + failure reason, IP, browser, OS, device type, session and timestamp. The user's name, email and branch are snapshotted onto the row, so the trail survives even if that person is later deleted.
* Live Users — who is online right now, their last action, last module, last location, last activity time, source (web/mobile) and their roles.
Supporting behaviour:
* Three ways to switch tracking on, OR'd together: a per-user toggle (also self-servable from Profile → Preferences), a per-role toggle (added later in the cycle — "track everyone who is a Sales CRE", and it keeps following the population as people join and leave the role), and a global all-users switch.
* Three-tier visibility: :view:all sees everyone, :view:branch sees users staffed at your branches, plain :view sees only yourself. New resource, so nobody inherits a legacy unfiltered view.
* Rows are purged automatically past the retention window.
* View modal is tabbed (Activity / Location / Device / System).
* Both tabs export, and the Live Users export matches exactly what the grid shows (roles column included).
* Filters were expanded mid-cycle from 3 to 10 on Live Users (User, Role, Last Action, Last Module, Last Location, Last Activity From/To), with searchable user/role dropdowns, and filters now persist between visits.
* The menu was moved out of Administration and re-parented under Permissions, next to Login History, and given the menu grants it was originally missing.
Exports — a broad correctness sweep
* "Export all entries (one row per entry)" checkbox added to the export modal as a reusable platform capability. Ticking it flattens a parent grid into one row per child record, repeating the parent block on each row. Adopted by Service Vehicles and Field Service Jobs (below).
* Excel dates now export as real dates, in your format. Previously exported timestamps didn't match what the grid showed. The converter now emits proper Excel date/time format codes, honours the user's configured date format, and separately handles date-only vs time-only columns. Location Tracking, Permission Audit and Delegation exports now pass raw timestamps through so the timezone renders correctly.
* Every export endpoint now returns through one shared method (createExportResponse + generateExportFilename). Roughly 20 controllers across dealer, automotive, platform and supply-chain had been hand-rolling their own content-type and filename logic; that's gone.
* New Service Approval Config export service.

### 2.5.8 — 2026-08-05

The old page at /dashboard/services/vehicles/performance was just a catalogue of report cards. It's now a proper role-based dashboard with 7 tabs, built the same way as the dealer Lead Performance hub and the Used Vehicle hub.
The tabs, and what each one actually answers:
* Management — Total Entries, Completed, In Workshop, Total Revenue, Completion %, Avg Turnaround, plus Service Activity Trend, Revenue Trend, Pipeline Composition, Revenue by Branch, Workshop vs Body Shop, and Entry Source Mix.
* Workshop Operations — Check-In vs Check-Out, WIP Aging (open vehicles by days since check-in), Delivery Commitment (open vehicles by promised date), Priority Mix, Temp-Out Status including vehicles physically off-site right now, Open WIP by Branch, and Status split by entry type.
* Branch Manager — volume, revenue, completion rate (green ≥80%, amber 60–80%, red below), avg turnaround (green ≤2 days, red above 5), overdue counts, a Bottom-5 branches list, and a full per-branch detail table.
* Service Advisor — the same shape per advisor, plus Commitment Load (overdue / due today / due this week) and a Discipline Score — 100 minus 5 per overdue promise and 2 per due-today promise.
* Revenue & Billing — Revenue Composition Trend, Estimate vs Final Variance (green = under quote, red = over), Ticket-Size Distribution, Payment Mode Mix, Payment Status Mix (customer / warranty / AMC / dealership), Revenue by Service Type, Discount by Branch.
* Vehicle & Customer Mix — Channel Mix, Top Models, Fuel Type, Transmission, Vehicle Age, Odometer at Check-In, Visit Frequency, Top Customer Cities.
* Reports — the original 10 report cards, preserved. ServiceVehicleReportsIndexPage.tsx was split so the card catalogue could be reused as a tab instead of duplicated, and its quick-stats fetch moved off useEffect onto React Query.

### 2.5.7 — 2026-08-04

Auditor role realigned across the whole product
The read-only AUDITOR role had drifted badly since it was created. Twelve migrations (one per module) now enforce a single rule: Auditor gets every read-shaped permission Admin holds, and loses every write verb — including every :export (deliberate product call: auditors read, they do not extract).
It also closed a latent security hole: several modules had granted Auditor a :view:all scope row without the base :view. Those rows are inert today because runtime authorities come straight from role_permissions and are never expanded through permission_dependencies — but the day anyone granted the base :view intending branch-scoped access, the dormant :view:all would have silently upgraded them to org-wide. Where a resource has no :view:all tier at all, Auditor simply mirrors Admin's tiers rather than inventing one.
Metric Info — explain-this-number system
A brand-new reusable component set (MetricInfoAnchor, MetricInfoButton, MetricInfoModal, MetricInfoTable). Every stat card, chart and table on the analytics hubs now carries a small info affordance; clicking it opens a modal explaining what the number means, how it's calculated, what it excludes, and — importantly — shows the live value for the current filter selection alongside the definition. Rolled out to 8 performance hubs (detailed under each module below).
One fix during rollout: the anchor's z-index was removed because it created a stacking context that pushed the popup behind open modals.
Sequential code generation — real production bug fix
Delivery numbers, quotation codes, driver codes and call IDs were being generated from a table row count. As soon as any row is deleted, the count falls behind the highest code already issued, and the generator starts re-issuing codes that are still taken — failing the unique constraint on every subsequent attempt. This actually happened: customer creation was blocked for an entire branch because the delivery count had fallen 21 behind.
New SequentialCodeGenerator derives the next sequence from the codes already issued for the same prefix, and compares them numerically rather than lexicographically — so 9999 → 10000 no longer wraps.
Email

## Related topics

[pasco one](https://appshunter.io/ios/topics/pasco-one)

---

*Data collected daily from the US App Store and indexed by [AppsHunter](https://appshunter.io/). User reviews are verbatim App Store reviews. Ratings, prices and chart positions refresh continuously; this snapshot is from 2026-08-20.*