¶ Admin permissions - roles and permissions in the panel

Admin permissions in Hummerce restrict access to the panel to selected sections and views - every store staff member sees and changes only what their role has permission for. The same permission model also applies to the AI assistant (MCP), so connecting the store to the assistant does not extend the permissions of the account it's connected with.

As of Hummerce 2.35 (2.35.55 or newer recommended; inactive account management from 2.35.63), updated 2026-10-16.

¶ Benefits and use cases

Access matched to the job - a salesperson handling B2B orders doesn't need to see store configuration, and a person handling configuration doesn't need access to all orders.
Restriction to selected views - an admin handling one sales channel (e.g. the wholesale view) sees only its orders and customers.
Secure AI assistant access - the MCP key has exactly the same permissions as the admin account it connects with - connecting the assistant doesn't open access to anything more.
Fewer unused accounts - an account that has not logged in for a long time automatically loses password login, and an admin can disable login on a former employee's account at any moment.
Advanced permissions on request - for unusual cases (e.g. access to only one object), permissions can be fine-tuned individually during implementation.

¶ How it works

¶ Roles and menu permissions

A role groups permissions to individual panel menu items (modules) and to store views.
Menu items the role has no permission for are not shown to the admin - the related modules also disappear from the panel's home page.
Roles are created and edited in Configuration -> Roles.

¶ Admins

An admin (panel user) has a login and password, and data such as first and last name, and is assigned to one or more roles.
An admin is also assigned to one or more store views - see below.
Admins are created and edited in Configuration -> Admins.

From version 2.35.63, Hummerce makes sure the panel does not keep accounts nobody uses.

Last login - every admin has a read-only field in the account data with the date of the last login to the panel. Every login renews it, and so does setting the password by an admin; it cannot be edited by hand.
Automatic closing of password login - in the store configuration, in the Admin accounts group, the Close the password login after days without a login setting defines after how many days without a login the account stops accepting its password. A value of 0 switches the mechanism off. A person with such an account sees a message at login asking an admin to set a new password - that is how the account is unlocked.
Marking on the list - on the admin list (Configuration -> Admins), an account with closed login has a red row and the Inactive - password login closed label, and an account disabled by hand has the Login disabled label.
Disable login / Enable login - a button next to the account on the admin list. A disabled account cannot log in with a password or an MCP key, and its open sessions stop working. Enabling lifts the automatic blocks and counts inactivity again from the day of enabling. The button is available only to the admin role, and an admin cannot disable their own account.

AI assistant tools for admin accounts: AI assistant - MCP server.

¶ View permissions

View permissions restrict the list of views available in the panel's top bar - an admin without permission to all views doesn't have the -- All -- option and doesn't see objects (e.g. orders) outside their views. Full description: Views - several stores in one panel.

¶ Quote specialist role

Pricing custom products (RFQ) requires a separate role - a quote specialist, who prices the submitted items and replies to the customer. Full description: Quotes - request for quote (RFQ).

¶ Advanced permissions

Beyond permissions to menu items and views, advanced permissions can be granted, tailored individually during implementation - e.g. access to only a selected object, or to only one operation on an object, instead of the whole module.

¶ Permissions in the AI assistant (MCP)

The AI assistant's API key is linked to an admin account and works exactly within the permissions of that account's role: an MCP tool the role has no access to in the panel is also unavailable via the assistant. Full description: AI assistant - MCP server.
In stores without the admin permissions module, there are no such restrictions - this applies to both the panel and the AI assistant.

¶ Version

Roles, admins and permissions to menu items and views - a core platform mechanism, available in all current versions.
Permissions enforced in the AI assistant (MCP), tool by tool - we recommend version 2.35.55 or newer.
Last login, closing login for inactive accounts and the Disable / Enable login button - from version 2.35.63.

¶ Dependencies

The admin permissions module - without it, the panel doesn't restrict access for any admin.
Restricting views in a role requires views configured in the store (Views).
The quote specialist role - the quotes module (Quotes).
Permissions in the AI assistant - a deployed MCP server (AI assistant - MCP server).

¶ Implementation

The permissions module works right after an update - the basic roles are part of the platform. A new role and assigning its menu and view permissions is panel configuration, with no code changes.
Advanced permissions (e.g. to a single object or a single operation) require implementation.
Minimum estimated time: a new role with menu and view permissions - from 1 h; an advanced permission - from 1 h per rule.
What the time depends on: the number of roles and admins, how granular the permission split is, the number of advanced permissions tailored to specific objects.

¶ Limitations

Without the permissions module installed, every admin has full access to the panel and to all MCP tools - restricting permissions requires this module.
A permission to a selected object or to just one operation on it (an advanced permission) must be configured individually - by default, a role restricts access to whole menu items and views, not individual records.
Automatic closing applies to password login. Disabling login on an account can only be done by an admin with the admin role.
The quote specialist role only applies to quotes - it doesn't replace the general admin role split.
We do not verify the task for legal compliance (e.g. licenses of submitted materials, GDPR, store terms of service).

¶ Future development

Ready-made role templates for typical positions (e.g. order handling, B2B salesperson).
A consolidated overview of an admin's permissions in a single panel view (today, role and views must be checked separately).

¶ Frequently asked questions

Does an account that has not logged in for a long time stay active in the store?
Partly. After the number of days set in the Admin accounts group, the account stops accepting its password until an admin sets a new one. A value of 0 switches this mechanism off.

How can I quickly cut off a former employee's access?
With the Disable login button on the admin list - the account stops working immediately, together with its open sessions and MCP key.

Does an admin see all modules in the panel?
No. They only see the menu items their role has permission for - the rest disappear from the menu and from the panel's home page.

Do permissions also restrict access to store views?
Yes. An admin without permission to all views only sees objects assigned to their views and doesn't have the option to preview all views at once.

Can the AI assistant (MCP) do more than the admin it connects with?
No. We recommend version 2.35.55 or newer - the MCP tool works exactly within the permissions of the role of the account it's connected with.

How long does setting up a new role take?
From 1 h for a role with menu and view permissions; advanced permissions are quoted separately, per rule.

Can a permission be granted for just one object rather than the whole module?
Yes, as an advanced permission implemented individually - by default, a role restricts access to whole menu items.

Views - several stores in one panel
Quotes - request for quote (RFQ)
AI assistant - MCP server
Admin panel and store security
On hummerce.com: B2B platform (in Polish)

Want to set up roles and permissions matched to your team? Contact the Hummerce team (in Polish).

¶ Configuration details

¶ Access in the admin panel

Roles: Configuration -> Roles - list and editing of roles, permissions to menu items.
Admins: Configuration -> Admins - login, password, personal data, assigned roles and views, and on the list the marking of inactive accounts and the Disable login / Enable login button.
Admin accounts: a settings group with the Close the password login after days without a login option.
Admin's views: view assignment in the admin's card; choosing the current view in the panel header.

¶ REST API and MCP

The MCP key is assigned to an admin account - every MCP tool call checks the same permissions the panel checks for that account (the same permission record as in the panel, with the same precedence rule - permission to the whole module includes permission to a single operation within it). A denial states exactly which permission is missing. Full description: AI assistant - MCP server.

Advanced permissions are stored in a format compatible with the Apache Shiro library (the object:operation pattern, with an asterisk as a permission for all operations on the object) - configured during implementation.

Permissions required by individual tools (to enter manually in the Advanced section when read-only access is needed):

Scope of work	Permission
order overview / changes / new orders	`order:view` / `order:update` / `order:create`
customers, searching by email and phone, segments	`customer:view`
abandoned carts	`purchaseBaskets:view` or `customerCart:view`
pricing and saving a cart for a customer	`customerCart:view` / `customerCart:update`
returns - read / change status	`return:view` / `return:update` (or `ro_reclamation:...`)
items - read and visibility diagnostics / changes / new	`item:view` / `item:update` / `item:create`
categories and virtual categories	`category:view`, `category:create`, `category:update`, `category:move`
price lists - list / item prices, customer price, price diagnostics	`priceList:view` / `priceListEntry:view`, `priceListEntry:update`
pricing rules	`itemPriceRule:...`, `customerPriceRule:...` or `cartPromotion:...`
promotions / coupons	`cartPromotion:view` / `coupons:...` or `newCoupons:...`
warehouse - stock, corrections, forecast / warehouses	`warehouseEntry:view`, `warehouseEntry:update` / `warehouse:view`
pages, content, canvases	`page:...`, `content:...`, `canvas:...`
photos	`image:update`, `imageUpload:view` or `itemImages:view`
properties / property locations	`property:...` / `property:edit`
views (assigning an object to a view requires permission to that object)	`view:view`
dictionaries: producers, VAT, currencies, units, groups, payments, deliveries, configurators	`producer:...`, `taxGroup:...`, `currency:...`, `unitOfMeasure:...`, `itemGroup:...`, `payment:...`, `delivery:...`, `combination:...`
sales statistics / bestsellers	`statistics:orders` / `statistics:items`
change history	`history:view`
configuration, modules, deployment status, database migration status	`configurables:view`
REST API diagnostics	`restApiDiagnostic:view`
scheduled tasks - list / run / clear cache	`tasks:view` / `tasks:Action` / `cacheAction:view`
data transfer - export / import	`transfer:view` / `transfer:*`
sending emails	`ro_mailForm:update`
store messages - read / write and remove	`bundlesEditor:view` / `bundlesEditor:update`
admin accounts - read / change properties	`user:view` / `user:update`
system information, guide, date, history vocabulary	no additional permissions

¶ Parameters

Permissions are saved as rules assigned to a role, not as object parameters. The only account parameter is the protected Last login field (a date, read-only, written by the platform).