Written by DROPS.ST.
Give a store manager access to the menu tasks they handle: keeping product details current, updating availability and making approved changes. Decide separately who can change prices, publish products, manage staff or alter payment settings.
Write those boundaries down before choosing a role called “manager.” Then test whether the shop software can enforce them. A role name alone does not tell you which actions it permits.
DROPS brings products, stock, orders and customer records into the same shop. Use that shared information to give your team clear responsibilities, then match each person's access to the work they handle.
Start with the manager's daily jobs
List the changes your manager makes during an ordinary shift. “Manage products” is too broad. Updating a photo, changing a price and deleting a product are different decisions.
For each task, answer three questions:
- Which products or menus should the manager work on?
- Can they make the change immediately, or does someone review it first?
- What information do they need to see?
For a business with several shops, also ask whether access can be limited to one location. A shared catalogue may mean that an apparently local edit changes every menu.
The security principle behind this approach is least privilege: give each person only the access needed for their work. OWASP also recommends denying access unless it has been deliberately granted. OWASP Authorization Cheat Sheet.
Use a permissions matrix you can explain
The following is a suggested starting policy for a manager responsible for menu maintenance. Adapt it to their actual job. It defines the access you should test when choosing a staff role.
| Task | Suggested manager access | Owner decision |
|---|---|---|
| Edit descriptions and images | Assigned menu only | Who approves product information? |
| Change availability | Assigned menu only | Does this affect other shops? |
| Change prices | Separate permission | Which prices may change? |
| Add, publish or delete products | Separate decisions | Who reviews new or removed items? |
| View customer records or export data | Exclude from menu-only role | Is another duty a reason to grant access? |
| Change payments, refunds or wallet settings | Exclude from menu-only role | Who owns each payment action? |
| Invite staff or change company settings | Exclude from menu-only role | Who grants access and controls the business account? |
If the manager also handles orders, add that work explicitly. Viewing an order, correcting its status and issuing a refund should each receive a separate decision.
Ask about bulk imports too. An account restricted in the product editor should not gain broader editing powers through a spreadsheet upload.
Test useful access and restricted access
Use clearly marked test products and fictitious records in a demo or test environment. Ask the provider to demonstrate sensitive actions there. Keep real payment destinations and customer records out of the exercise.
Record the account used, action attempted, expected result and actual result. An owner account and a manager account should be tested separately.
1. Can the manager complete an ordinary edit?
Change a test product's description and availability. Save it, reopen it and inspect the menu.
Expected: the assigned product changes correctly. Unrelated products remain unchanged. The manager can finish the task without borrowing the owner's login.
2. Does another menu remain outside their access?
If location restrictions are required, prepare a test product for another location. Ask the provider to show what the manager can see and edit.
Expected: access matches the written policy. If both locations share the same product record, establish the effect of editing it before accepting the setup.
3. Are price and publication decisions separate?
Try the agreed ordinary edit, then have the provider demonstrate changing a price or publishing a new test product.
Expected: each action follows its own policy. Permission to correct a description should not silently grant every product action.
4. Are account and payment controls restricted?
Check staff invitations, permission changes, company settings, customer exports and payment configuration.
Expected: a menu-only manager cannot perform these actions. If the platform groups them together with menu access, record that limitation and reconsider the role.
5. Does the restriction hold beyond a hidden button?
Ask the provider to demonstrate the same restricted action through a saved page address or another supported route, using harmless test data.
Hiding a menu item is insufficient protection. OWASP advises checking authorization on every request and enforcing access outside the browser interface. OWASP Authorization Cheat Sheet.
Expected: the action is refused and no restricted change occurs.
6. What happens when access changes?
Have the provider remove the test manager's menu permission while their session is open. Refresh the page and attempt another harmless edit.
Expected: access changes take effect according to a documented rule. Ask whether active sessions must be ended separately and who can do that.
These tests demonstrate particular boundaries. They do not establish that every part of a platform has been security-tested.
Hypothetical example: one owner, two shop managers
An owner operates two shops with a shared catalogue. Each manager needs to mark local availability and correct menu images. The owner keeps control of prices, payment settings and staff access.
During evaluation, the provider explains that images belong to the shared product record. Availability can be handled separately, but replacing an image changes both menus.
The owner adjusts the proposed workflow: managers handle local availability, while shared image changes go to a named reviewer. If the software cannot enforce that division, the owner keeps shared edits with the reviewer rather than granting broader access.
This hypothetical example shows why the object being edited matters as much as the role name. It is not a customer case study or a description of verified DROPS functionality.
Decide how changes will be reviewed
Ask whether the platform records who changed a product, when it changed and what the previous value was. Also ask which actions that record covers and who can inspect it.
If detailed change history is unavailable, agree on a practical review process and state its limits. A shared request list can coordinate edits; it does not prove who made a change inside the software.
Keep a named contact for corrections so managers know how to resolve an incorrect price or description.
Give your team clear responsibilities in DROPS
DROPS puts products, stock, orders and customer records together, so your team works from the same shop information. Website and connected Telegram shopping share the catalogue and order system. Keeping the menu current becomes part of running one shop.
Order responsibilities have separate controls: viewing orders, changing status, assigning work, marking payments, cancelling orders and handling refunds. Shop settings require an administrator. That gives you concrete actions to divide between the owner, managers and order staff.
Match the role to the full job. Current catalogue-edit access also covers customer-account edits and wallet adjustments. Treat it as a broader shop-management role and grant it to staff trusted with those duties. A menu-only employee should use an owner-reviewed request process when that broader access is inappropriate.
Use the matrix above to agree on who does what, then demonstrate the chosen roles before launch. Keep any required location restrictions or detailed change history on that test list.
See DROPS in action and explore the demo shops. Follow a product into an order and see how the shop's information stays connected. Choose DROPS to bring daily shop work together and give each person a clear responsibility.
Customer access is a separate decision. The password-protected shop guide explains that boundary.