User Permission Manager
One tile on the CP Commerce Admin webstore dashboard, not an applet of its own: it gives a named person access to CP Commerce Admin for this tenant by installing the applet for them and adding them to one tenant role, or sends an invitation when the address has no account yet. It has no document and posts nothing. The screen reports nothing when an action fails, and a newly promoted person has to sign out and back in before the Website Builder opens for them.
Your job, and the screen for it
| The job | Screen or tab | Read |
|---|---|---|
| Give a person access to CP Commerce Admin — they must sign out and in before it opens for them | Add New Admin User › Verify User, then Make Admin | Lifecycle and effects |
| Invite someone with no account yet — finishing the sign-up gives no applet and no role, so come back and verify again | Add New Admin User › Verify User › User Not Found › Send Invitation | Lifecycle and effects |
| Check who is in the admin role, and that a new admin can work — the list misses anyone holding the applet without the role | Admin Users list; Menu Manager after the person signs out and in | After Make Admin: check the person can work |
| Take access away — Remove Access removes the role only; uninstall CP Commerce Admin too, then have the person sign in again: Menu Manager must refuse them | Trash icon on an Admin Users row › Remove Access; Tenant Admin to uninstall | Lifecycle and effects |
| Find out why a button did nothing — the screen reports no failure | Browser console and network tab | Troubleshooting |
| Get the screen ready — a Website record with its website-builder configuration, an ACTIVE role, and rank ADMIN or OWNER for you | CP Commerce Admin (Website record); Tenant Admin (Tenant Roles, ranks); the configuration itself is set by BigLedger | Before you can use it |
Overview
The User Permission Manager is one tile on the Webstore Management Dashboard that the CP Commerce Admin applet opens — the Website Builder area served by the Customer Portal storefront app itself. It is not an applet of its own and has no row in the applet registry.
It does one job: give a named person access to CP Commerce Admin for this tenant, and take it away again. Behind the two buttons it installs the CP Commerce Admin applet for that person and links them to one tenant role; if the e-mail address has no Akaun account yet, it sends them an invitation to create one first.
Everything on the screen depends on a small website_builder_config block stored on the Website record. There is no screen anywhere that writes that block — see Configuration.
Where it fits
| Piece | What it does | Where it is configured |
|---|---|---|
| Webstore dashboard tile | Opens /page/website-builder/layout-menu/user-permission-manager on the storefront. | Shown unless the website carries HIDE_USER_PERMISSION_MANAGER = 'true'. |
| Website record | Supplies the five identifiers the screen needs: the applet, its catalogue and catalogue link, the tenant, and the role new admins are added to. | No screen writes them — see below. |
| Applet access | What makes CP Commerce Admin available to that person, and the only thing the storefront’s admin mode depends on. | Granted by Make Admin; also managed from Tenant Admin. |
| Tenant membership | Says the person belongs to the tenant, and at what rank. This screen’s own actions require rank ADMIN or OWNER here. | Created at rank GUEST if the person was not already in the tenant; raised elsewhere. |
| Role membership | What the Admin Users list shows and the trash icon removes. | Added by Make Admin, removed by Remove Access. |
| Invitation | The pending sign-up created by Send Invitation. | Finishing the sign-up adds the person to the tenant; it does not grant admin. |
Upstream: CP Commerce Admin owns the Website record this screen reads. Downstream: nothing — the person you promote here uses CP Commerce Admin and the Website Builder, and those pages describe what they can then do.
Screens and menus
One page, two cards and one dialog.
- Add New Admin User — an Email Address box and a Verify User button. After verification the card shows either a green User Verified Successfully! panel with a Make Admin button, or an amber User Not Found panel with a Send Invitation button. Only one of the three buttons is visible at a time.
- Admin Users — a table of everyone linked to the configured role, with a refresh button in the card header, and Previous / Next paging that appears only when there are more than 10 rows.
- Remove Admin Access — a confirmation dialog with Cancel and Remove Access, opened by the trash icon on a row.
A back arrow returns to the Webstore dashboard.
Configuration
Before you can use it
- A Website record in CP Commerce Admin for this storefront, carrying the website-builder configuration described below.
- An ACTIVE tenant role to put new admins in. Roles are created in Tenant Admin (Tenant Roles). The backend rejects the role link if the role does not exist or is not
ACTIVE. - The CP Commerce Admin applet published in a catalogue, so that a catalogue guid and catalogue-link guid exist to install from.
- Rank
ADMINorOWNERon the tenant for you, the person using the screen. Send Invitation and Make Admin both check it (a platform system administrator also passes the install check). Without it every button fails — silently, see Troubleshooting.
The website-builder configuration
The screen reads five values from the website’s configuration when it loads. No screen in CP Commerce Admin or in the Website Builder sets them; they are set by BigLedger when the storefront is commissioned. If the screen misbehaves in one of the ways below, ask for them to be checked.
| Value | What it is used for | What happens when it is missing |
|---|---|---|
| Applet | Identifies CP Commerce Admin when granting it. | The grant is refused; Make Admin appears to do nothing. |
| Catalogue | The catalogue the applet is installed from. | As above. |
| Catalogue link | The catalogue’s entry for the applet; its rank is used when none is given. | As above. |
| Tenant | The tenant the grant is made in. | As above. |
| Role | The role new admins are added to, and the only filter on the Admin Users list. | The list never loads at all, so the card shows No Admin Users Yet however many admins exist. Make Admin grants the applet and then fails on the role step. |
Showing and hiding the tile
The Webstore dashboard hides any of its thirteen tiles whose website setting HIDE_<TILE> is the literal string 'true'. For this tile the setting is HIDE_USER_PERMISSION_MANAGER, default false (the tile shows).
Eleven of the thirteen tiles have a checkbox under Website → edit → Details → Hide Website Builder Elements in CP Commerce Admin. HIDE_USER_PERMISSION_MANAGER is not one of them — neither it nor HIDE_HIGHLIGHT_ACTIVITY_MANAGER has a control. To hide this tile the setting has to be written through the website API.
Hiding the tile hides the tile only. The route /page/website-builder/layout-menu/user-permission-manager still resolves for anyone who types it.
Feature visibility and permissions
There are no client-side permissions for CP Commerce Admin, and this screen checks none.
Any signed-in storefront user can open this page — hiding the tile does not stop them. What they can do on it is decided by the server:
| Action | Who may do it |
|---|---|
| Verify User | Needs MST_API_APP_LOGIN_PRINCIPAL_READ. An account you may not read comes back masked (PERMISSION_DENIED), not hidden. |
| Send Invitation | Rank ADMIN or OWNER on the tenant; otherwise not authorised. |
| Make Admin — grant the applet | Rank ADMIN or OWNER on the tenant, or platform system administrator. |
| Make Admin — add to the role, Remove Access | Tenant owner/admin, or one of TNT_LOG_TEAM_ROLE_ASSIGNMENT_OWNER, TNT_LOG_TEAM_ROLE_ASSIGNMENT_ADMIN, TNT_API_TEAM_ROLE_ASSIGNMENT_CREATE (add) / TNT_API_TEAM_ROLE_ASSIGNMENT_DELETE (remove). |
| Admin Users list | Checked per row; rows you may not read come back as PERMISSION_DENIED placeholders instead of being dropped. |
Fields
Add New Admin User
| Field | Meaning | Required | Notes / validation |
|---|---|---|---|
| Email Address | The person to look up. | Yes | Must look like an e-mail address; trimmed before use. Disabled while verifying and after a successful verification. Pressing Enter runs Verify User. The lookup is an exact, case-sensitive match on the account’s e-mail sign-in, so an account registered by mobile number is never found. |
Admin Users
| Column | What it actually shows |
|---|---|
| User | Always the part of the e-mail address before the @, never the person’s real display name. |
| Status | The status of the person’s role membership, not of their account — normally ACTIVE, or PERMISSION_DENIED when you may not read it. |
Paging is fixed at 10 rows.
Lifecycle and effects
This screen changes who can do what, and nothing else. It has no document, no journal entry and no stock movement.
Verify User looks for an Akaun account whose e-mail sign-in is exactly that address. No match → User Not Found and the invitation button. A match → Make Admin appears. Verification says only that an Akaun account with that address exists somewhere on the platform; it says nothing about this tenant.
Send Invitation sends an Invitation to AKAUN e-mail (subject and body can be changed per tenant through the messaging templates) with a confirmation link to the sign-up page. When the invitee finishes registering they are added to the tenant — at rank GUEST, with no applet and no role. You still have to come back, verify the address again and press Make Admin before CP Commerce Admin opens for them.
Make Admin runs two calls in order and then reloads the list:
- Grant the applet — CP Commerce Admin, at rank
ADMIN. The person is added to the tenant if they are not there yet (rankGUEST), the applet is made available in the tenant if it is not there yet, and an existing grant is updated, keeping the higher of the two ranks. - Add the person to the role, with an audit-trail entry
LINK_SUBJECT_TO_ROLE/LINK_ADDED.
The two steps are not all-or-nothing. If step 2 fails — most often because the person is already in the role — the applet stays granted and the person is left half-promoted.
Remove Access removes the person from the role only (with an audit entry LINK_SUBJECT_TO_ROLE / LINK_DELETED). It does not take the applet away. Admin mode in the Website Builder is decided by the applet grant, so a person you remove here keeps CP Commerce Admin and keeps the Website Builder in admin mode. To take that away, uninstall the applet for that person in Tenant Admin.
When the change takes effect. The storefront asks for a CP Commerce Admin applet token once, as part of loading the session after sign-in; that token is what turns admin mode on. A newly promoted person therefore has to sign out and back in before the Website Builder opens for them.
Whether the Website Builder opens for a person
Nothing on the dashboard says why one person sees a working screen and the next sees a refusal, and none of it is a permission set in the way the rest of BigLedger is:
- You sign in on the storefront with the same kind of login a shopper uses. A person who is not signed in and types a Website Builder address is sent to the Website Builder’s own sign-in page.
- The storefront asks once, as your session starts, for a CP Commerce Admin applet token. If one comes back, the session is in admin mode; if none does, nothing asks again until you sign out and in.
- The dashboard opens for any signed-in person; the tiles differ. Six — Menu Manager, Layout Manager, Notification, Voucher Management, Activity Manager and Event Manager — show the fixed text Only Admin can access this page when the session has no applet token (it says nothing about the role, or about a grant made after you signed in). The other five — Product Management, Shipping, QR Code Manager, Highlight Manager and User Permission Manager — open for anyone signed in, and what they then load or save is decided by the server against that person’s own login, because every call the Website Builder makes carries the signed-in person’s token.
- The applet is what gets installed, not a rank or a role. Being in the role without the applet opens nothing; holding the applet without the role opens everything and leaves the person off this tile’s list.
Deciding who holds it is a person’s job. This tile grants CP Commerce Admin to any address an existing admin types, keeps no list of who ought to hold it, and tells nobody when someone is added. In a group like GadgetSphere the holder is the online store’s manager at GSO. Settle before the first promotion who may be made admin, and whether the store manager may touch products (the Product Management tile edits the item master every channel reads), and write the answers down; the product has no field for either.
After Make Admin: check the person can work
The product will not tell you, so the administrator who pressed Make Admin checks. Two minutes:
- Have the person sign out and in, then open Menu Manager. The menu list, not Only Admin can access this page, is the proof that their session fetched the applet token.
- Find their address in Admin Users. If they can open Menu Manager and are not in the list, they hold the applet without the role — fine for working, invisible to the list.
- After a removal, finish it in Tenant Admin and have the person sign in once more: Menu Manager must now refuse them.
- Once a month, read Admin Users against the list of people who should hold it. The product keeps no such list and announces no addition. Write down who reads it.
Related applets
- CP Commerce Admin — owns the Website record this screen reads, and is the applet this screen grants. Its Website → Details tab holds the eleven tile-hiding checkboxes.
- Tenant Admin — where the role is created, where tenant ranks are raised above
GUEST, and the only place an applet link can be uninstalled. - Shopping Cart — the storefront’s other back-office touchpoint; unrelated to access control, listed because both sit on the same Customer Portal website.
Troubleshooting
The screen reports nothing when an action fails: the spinner stops and the form resets. “Nothing happens” is the normal symptom of every problem below, so open the browser console and the network tab before anything else.
| Symptom | Cause | Fix |
|---|---|---|
| Every button does nothing; the console shows a not-authorised response | You do not hold rank ADMIN or OWNER on the tenant link. Note that being made an admin by this screen does not grant that rank — new admins get GUEST. | Raise the rank in Tenant Admin, or have somebody who already holds it do the promotion. |
| User Not Found for an address that certainly exists | The lookup is exact and case-sensitive, and only matches e-mail sign-ins. An address stored with different capitalisation, or an account registered by mobile number, will not match. | Use the exact stored address; for phone-registered accounts add the person from Tenant Admin instead. |
| Verify User neither confirms nor reports Not Found | The account came back masked (PERMISSION_DENIED) because you lack master-level read on it, and the screen stops. | Have somebody with the master read permission verify, or add the person from Tenant Admin. |
| Make Admin does nothing on the second attempt | The person is already in the role and the server refuses the link as already existing. | Refresh the list — the person is already there. |
| The applet was granted but the person is not in the list | Step 2 failed. Usually the role is missing from the website configuration, or the role is not ACTIVE. | Have the role set on the website configuration, then press Make Admin again — granting the applet twice does no harm. |
| The list says No Admin Users Yet although admins exist | The role is missing from the website configuration, so the list is never asked for. | Have it set by BigLedger. |
A row shows PERMISSION_DENIED and N/A | You may not read that person’s role membership; you get a placeholder rather than no row. | Grant the role-read permission, or ignore the row. |
| Somebody you removed still reaches the Website Builder and CP Commerce Admin | Remove Access removes the role membership only; the applet grant is what gives access. | Uninstall the applet for that user in Tenant Admin. |
| A new admin sees the storefront but not the Website Builder | The applet token is fetched once per session. | Sign out and back in. |
| The tile is missing from the Webstore dashboard | HIDE_USER_PERMISSION_MANAGER = 'true' on the website. There is no checkbox for it in CP Commerce Admin. | Change the setting through the website API, or open the page’s address directly. |
Related documentation
- CP Commerce Admin applet — the Webstore dashboard, the Website record and every other tile.
- Push Notification Configuration — the other Customer Portal feature configured through the website record rather than a screen.
- Tenant Admin applet — roles, ranks, applet installs and uninstalls.
- E-Commerce module