Design employee storage with access to your own belongings
Define owner-only employee access and the implementation work needed to enforce it.
Before you begin
- Treat this as a solution design. The current booking-PIN kiosk does not enforce employee ownership at the door.
- Define an employee identity, an assigned compartment or active storage booking, and the intended access period.
- Choose the personal authentication methods that the installation will implement and enroll.
Solution design based on integrate-nekospaze-app at 5d1abe32660e, reviewed 8 September 2026. Owner-only personal storage is not enforced by the current application and requires implementation.
Step by step
Assign each storage session to its owner
Record which employee owns each compartment assignment or storage booking. The required policy is that an employee can open only their own active storage compartment. A general employee role or a shared office PIN must not grant access to colleagues' belongings.
Authenticate the employee
Implement the selected face, personal QR, card/MIFARE/NFC, phone-and-passcode, or email-and-password method to resolve a verified person. Confirm the reader and credential compatibility first. These methods are not connected to personal locker authorization in the current kiosk.
Authorize the exact compartment before opening
The implementation must bind the identified employee, active owner assignment, project, device, resource, and requested action in one decision before a physical open. Reject a colleague's compartment even when the employee can sign in or knows its number.
Separate reopening from ending storage
Define an owner reopen action for retrieving or adding belongings during the assignment, and a distinct finish action that releases it. The current PickUp action ends the booking and revokes all codes, so it is not a reusable employee access session.
Define a scoped maintenance exception
Implement a separate authenticated staff path for named maintenance actions on allowed resources. Record the actor, reason, target compartment, command result, and resulting booking state. Current staffAuth settings and hidden entry gestures do not enforce this exception.
Pass the ownership scenarios
Test two employees with different compartments, a revoked employee, an expired assignment, an incorrect or copied credential, and a scoped maintainer. Repeat during disconnect and reconnection under the chosen offline policy before offering owner-only storage.
You’re ready when
An implementation brief and acceptance criteria for employees to access only their own belongings; this policy is not yet a shipped kiosk capability.
Troubleshooting
- A colleague can open a locker using a copied PIN
- That is compatible with the current bearer-code design. Enforce verified owner identity in the command authorization path before deploying the owner-only policy.
- A reader recognizes an employee but opens no locker
- Recognition does not resolve the active compartment entitlement. Implement and test the identity-to-assignment decision after credential verification.
- An owner picks up one item and loses access
- The current PickUp action completes the booking. The proposed employee-storage flow needs a separate owner reopen action and explicit finish action.
Technical details
- Acceptance: owner access
- Employee A authenticates and opens A's active compartment; the same credential cannot open employee B's compartment. Denial sends no open command.
- Acceptance: ownership changes
- After reassignment or revocation, the previous owner cannot open the compartment. The new owner obtains access only through the new active assignment.
- Acceptance: invalid or expired access
- An unknown credential, wrong project, wrong device, or expired assignment is denied before opening, with a useful reason that does not reveal another employee's belongings.
- Acceptance: storage lifecycle
- Owner reopen preserves the assignment; explicit finish releases it and removes further owner access. Failed commands do not falsely record collection.
- Acceptance: staff scope
- A maintainer authenticates separately and can perform only assigned maintenance actions on allowed compartments. Employee credentials cannot enter that path.
- Acceptance: disconnected operation
- Test stale ownership, revocation, expiry, and reconnect reconciliation. Define which decisions can be made offline; deny access when required authority is unavailable.
Common questions
- Can a Console owner field make access owner-only?
- It records ownership in that Console workflow. It does not add a person check to the current kiosk's code match and serial opening.
- Can booking participants access an employee's locker?
- Do not assume so. Participation is not a locker authorization grant in the current kiosk. The requested office policy allows only the owner; any delegate would need a separately specified policy.
- Can employees use a personal credential instead of a booking code?
- That is the proposed experience. It requires credential verification, identity-to-owner authorization, and physical-command enforcement to be implemented together.
Still stuck? Tell support what happened and which step you reached.
Email support