Staff Dashboard Security

The staff dashboard sits behind WordPress login by default. That’s enough for shops where the dashboard lives on a private machine and one person uses it. For shops with a tablet on the warehouse counter, casual staff, or anyone walking past who shouldn’t be able to see customer data — the security settings layer extra protection on top.

All settings are off by default. Turn on what your situation needs.

—

What’s available

At Tracksies > Settings > Packsie > Security: Staff PIN, three independent layers:

1. Staff PIN — second-factor PIN gate sitting on top of WP login
2. Idle lock — auto-locks the dashboard after a configurable period of inactivity, requires PIN to resume
3. PIN re-entry on refund — extra PIN prompt at the moment a refund is authorised

You can turn any of these on independently. The PIN gate is the foundation; idle lock and refund-PIN-re-entry both depend on PIN being set up first.

—

The Staff PIN

What it adds

After WordPress login, staff users hit a PIN modal before the dashboard renders. They enter their PIN once, the system marks the session as PIN-validated for the configurable session duration (default 8 hours), and they can use the dashboard normally for that period without re-prompting on every page load.

Per-staff PINs — each user has their own. 4 to 12 digits. Hashed at rest using the same hashing WordPress uses for passwords; nobody (including you) can see another user’s PIN.

Common PINs are rejected at set time

The system rejects obviously-guessable patterns when a PIN is being set:

• All-same-digit (0000, 1111, 222222, etc.)
• Sequential (1234, 4321, 12345, 654321)
• Common patterns (1010, 1212, 121212, 123123)
• Repeated combos that show up in standard dictionary lists

If a user tries to set one of these, they get a “PIN is too common — pick something less guessable” error and have to choose differently. You can disable this rejection from the settings if you really need to (not recommended), but it’s on by default.

Two ways a user gets a PIN

Self-serve on first dashboard access — when PIN is enabled and the user has no PIN yet, the modal flips into “Set up your PIN” mode with a confirm field. They pick their PIN, confirm it, and it’s stored.

Admin sets it on their behalf — useful for onboarding. Go to Users > Edit a user in WordPress, scroll to the Packsie Staff PIN section. As an admin, you can:

• Set a PIN (or replace an existing one) — useful when sitting with new staff at the warehouse counter
• Clear a PIN — forces the user to set a new PIN on next dashboard access, useful when you don’t want to know their PIN
• Clear a lockout — for legitimate users who have mistyped a few times (without forcing them to set a new PIN)

The user profile section also shows current PIN status, last-changed time, and current lockout level if any.

Brute-force protection

The PIN system has escalating lockouts so guessing isn’t viable:

The 1-hour cumulative window is short enough that an honest mistyper-during-tea-break starts fresh, but long enough that an attacker can’t rest 5 minutes between bursts to skip the escalation.

A 6-digit PIN with this scaffolding takes thousands of lockouts to brute-force the keyspace — practically infeasible. Without the scaffolding, the same PIN is solvable in seconds. The scaffolding is what makes the PIN actually secure.

Admins are exempt

Administrator-role users don’t see the PIN modal. Same for idle lock and refund-PIN-re-entry. The reason: admins are the recovery path. If PIN config gets corrupted, if a user gets stuck, if the system needs unsticking, admins are the people who do that. Locking them out alongside everyone else means there’s no escape hatch.

If your concern is admin accounts specifically, the right answer is two-factor authentication for those accounts via a paired plugin (WP 2FA, Two Factor, etc.) — that’s a separate axis from the staff PIN gate.

—

Idle lock

What it does

After the configurable period of inactivity (default 1 hour), the dashboard locks behind a full-screen overlay. Staff have to enter their PIN to resume. Activity = mouse movement, key press, scroll, touch, or click.

While the overlay is showing, dragging across it doesn’t count as “activity” against the lock — only successful PIN entry resumes. So you can’t accidentally extend a session by leaning on the keyboard.

Long-lock threshold

The “long lock” threshold is the limit beyond which PIN alone won’t resume — the user is logged out and must do a full WordPress login. Default 8 hours. Useful for shift-end and overnight scenarios where you’d rather not let yesterday’s PIN session unlock today’s.

The choices:

• 4 hours — short shifts; tighter session boundaries
• 8 hours — typical workday (default)
• 12 hours — extended shifts
• Never — PIN always sufficient to resume regardless of how long it’s been

What the locked screen shows

Three states:

• Resume with PIN — PIN input + Resume button (default state when idle threshold hit)
• Locked out — countdown timer + “Try again in X:XX” (if too many wrong PIN attempts during resume)
• Session expired — “You’ve been away too long. Sign in again” + button to wp-login (when long-lock threshold passed)

—

PIN re-entry on refund

When this is on, every Approve click on a refund request in the manager approvals queue asks for the PIN again — even if the user’s PIN session is still valid.

Why: refunds move money. Even within an unlocked session, this gives you a small confirmation gate at the moment money moves. Useful for shops where the same person packs and approves and you want one extra check before pressing Approve on something high-value.

Implementation detail: the PIN check uses a single-use token that expires in 60 seconds and can’t be replayed. So even if someone intercepts the token in transit, they can’t reuse it for a different refund or replay it later.

Substitute and return-resolution approvals don’t ask for PIN re-entry (they’re decisions, not money moves). Only refund-shaped approvals do.

—

Configuration

At Tracksies > Settings > Packsie > Security: Staff PIN:

When the master “Require PIN” is off, the other PIN-related settings have no effect (they’re conditional on PIN being on).

—

What gets logged

The Packsie audit log captures three kinds of events.

PIN events

• PIN set — by user (self-serve) or by admin
• PIN validated — successful entry on dashboard load or idle resume
• PIN failed — wrong PIN attempt with current attempt count + lockout level
• Admin reset PIN — admin cleared a user’s PIN
• Admin cleared lockout — admin unlocked a user without forcing PIN reset
• PIN action validated — refund approval went through with valid PIN re-entry token
• PIN action failed — refund approval blocked by failed PIN re-entry

Customer profile views

• Customer profile viewed — every load of the Customers tab profile panel, with the customer ID and whether they’re a registered WordPress user or a Tracksies-only customer

Logged BEFORE the profile renders, so the access record still exists even if rendering hits an error. Useful when you need to answer “who looked at that customer last week?”

Other dashboard events

• Refund authorisations — immediate, queued for manager approval, approved, rejected
• Manager approvals — substitute approvals, return-resolution approvals (refund / replace / reject)
• Approval notes — posted to the notes thread on a pending action
• Return items restocked — when a returned item is pushed back to inventory

Filterable by user so you can see “this user has had 8 failed PIN attempts in the last hour” or “this user viewed 12 customer profiles in 30 minutes” at a glance.

—

Common questions

A staff member forgot their PIN. What do I do?

As an admin, go to Users > Edit that user > Packsie Staff PIN section > Clear PIN. They’ll be prompted to set a new PIN on their next dashboard access. You don’t need to know what their previous PIN was.

A staff member got locked out from too many wrong attempts.

Same place, same section: click Clear lockout. This unlocks them without forcing them to set a new PIN — useful when the lockout was from honest mistyping rather than a security concern. If you’d rather force a PIN reset too, use Clear PIN instead.

Can I see staff PINs in the database?

No. PINs are hashed using the same one-way hashing WordPress uses for passwords. The actual PIN string can’t be recovered from the stored hash by anyone, including you, including a database administrator.

A user changed their own PIN. Can I see what they changed it to?

No, for the same reason as above. You can see WHEN they changed it (last-changed timestamp on their user profile) but not WHAT they changed it to.

Idle lock fires too often / not often enough.

Adjust Idle timeout in settings. The four options (15 / 30 / 60 / 120 minutes) cover most scenarios. If 15 minutes is too aggressive but 30 is too lenient, the right answer is usually that the threshold matters less than the setup — for high-traffic warehouse devices, even 60 minutes is fine because activity is constant; for office-style use, 30 minutes is more typical.

The dashboard locked while I was actively reading something on screen.

“Activity” requires actual interaction — mouse movement, key press, scroll, touch, or click. Reading without scrolling counts as idle. If you’re frequently reading long content without scrolling, increase the idle timeout. The trade-off: longer idle = more risk if someone walks away and forgets to lock.

Can I disable the long-lock threshold completely?

Yes — set it to “Never”. The user can resume with PIN regardless of how long they’ve been idle. Trade-off: a tablet left on overnight is unlocked first thing the next morning with just a PIN. If you don’t have a physical-security risk (tablet in a locked room, etc.), this is fine.

—

Related

• Manager Approvals Queue — How refunds get approved (the workflow that PIN-re-entry-on-refund gates)
• Staff Roles & Access Control — Who can access the dashboard at all (the layer beneath PIN)
• Debug Logging — How to capture PIN events for support troubleshooting