Applet Store

Install applets onto your own login from the catalogues an administrator has opened to you. Every install is for one login, never for the whole tenant, and a private catalogue appears here only because Tenant Admin linked you to it. Nothing here is bought or paid for: the store carries no price, plan or order, and a paid applet is arranged outside it.

Overview

The Applet Store is the platform screen where a signed-in user browses the applet catalogues their login has been granted and installs applets onto their own account. It is the screen every “install the X applet” instruction on this site points at.

Two things about it decide almost everything else on this page. First, installation is per user, not per tenant: each install writes one row linking your login to one applet in one catalogue, and the backend refuses an install submitted for anybody else’s login. Second, what you can see is decided elsewhere — a catalogue is public or private, and a private catalogue reaches you only because an administrator linked your login to it in the Tenant Admin Applet.

Its registry row is appletStore, name Applet Store, applet_type ROOT-USER, status ACTIVE. It has no settings of its own (see Configuration).

Where it fits

Screens and menus

Everything is mounted under applets/bigledger/akaun-platform/applet-store. There is no sidebar: navigation is the three-link bar at the top of the listing screens.

The Terms of Use gate

A guard runs before every screen in the store. It reads the signed-in user’s profile extensions and looks for a parameter whose code contains APPLET_STORE_TNC with a truthy numeric value. If it is there, you go straight through and never see the dialog again. If it is not, a full-height, non-dismissable dialog opens with the Akaun.com Marketplace Terms of Use, an I have read the terms and conditions checkbox, and Accept / Decline buttons. Accept is disabled until the checkbox is ticked. Accepting writes the acceptance to your user profile (see Lifecycle and effects); declining bounces you back to the launchpad.

Acceptance is recorded per login, not per tenant or per company. A new colleague sees the dialog on their first visit even though everyone else in the business has accepted.

The listing screens

All three listing screens render the same component, so they look alike:

• A header bar reading Catalog, with links Public, Private and My Applets.
• A Search for applets box. It filters the rows already loaded in the browser — it does not re-query the server. On the Public and My Applets tabs it matches the applet name; on the Private tab it matches the applet name or the catalogue name, after a short typing pause.
• A grid of applet cards.
• On the Public and Private tabs only, an Install All button. It is greyed out when every applet on screen is either already installed or blocked from installation.

The Public tab loads every public catalogue in one request and shows the applets as one flat grid, each card carrying its catalogue’s name. The same applet offered by the same tenant at the same rank is shown once even if it sits in two catalogues.

The Private tab loads one catalogue per request. Scrolling to the bottom — or pressing the Load More button below the grid — fetches the next one, so a user with many private catalogues reaches them a page at a time rather than all at once.

My Applets shows the heading My Installed Applets and lists what your login has installed. It has no Install All button and no uninstall control; uninstalling is done from the applet’s detail screen.

Below 500 px of viewport width the listings switch themselves to a dark theme. Above it they are light. This is a width test, not an operating-system preference test.

The applet detail screen

Clicking any card opens the detail screen, which is laid out like a consumer app-store listing:

• Hero — icon (clickable, opens full size), name, and up to four stats: Rating (the average, or “No ratings”), Rank, Tenant, Status (Installed / Not installed).
• Documentation button — opens the applet’s documentation URL in a new tab. It is disabled when the registry row for that applet has no documentation URL.
• Share button — uses the browser’s native share sheet where one exists, otherwise copies the current page URL to the clipboard and confirms with a toast.
• Install, or — once installed — Uninstall and Open.
• Preview — a horizontally scrolling gallery of the applet’s screenshots, ordered by their sequence number. The whole section is hidden when the applet has no images.
• About this app — the description, plus Version and Updated on when the registry carries them. With no description it reads No description is available for this applet yet.
• Rate this applet / My review — a five-star row, and a Write a review / Edit your review link that opens a dialog with the stars and a comment box capped at 500 characters.
• Ratings and reviews — the average, a five-bar histogram of one- to five-star counts, the total count, and other users’ reviews. Your own review is lifted out of that list into the section above it.

Configuration

Before you can use it

Applet settings

The store has no settings of any kind. The only per-user state it writes is your acceptance of the Terms of Use.

Settings in other applets that control this applet

Feature visibility and permissions

The Applet Store has no client-side permissions. Nothing in the store is hidden or shown by a permission set. Authority is enforced on the server, per endpoint:

What an installed row actually buys you

The installed link is not decoration, and it is not a complete answer either. Both halves matter if you are deciding who may open what.

It is a real gate, once. An applet cannot talk to the platform with your ordinary login token. On start-up it exchanges that token for an applet token, and the server issues one only after checking that the applet is installed for your login in that tenant; without it the exchange is refused with One or more Applet/Tenant Code combination does not exist. So “uninstall it and they cannot use it” is true.

Past that gate, the API is not organised by applet. Server-side permission codes are named for the resource they protect — a customer, a document, an export — never for an applet, and the applet identity carried in the token is read almost exclusively to stamp the audit trail. Two endpoints on the whole platform require an applet token at all. The practical consequence for an access model: installing fewer applets tidies what a person can reach through the screens; it is not a restriction on what their login can do through the API. The restriction that survives a determined person is the permission set, not the applet list.

And an install can quietly admit somebody to a tenant. Granting an applet also makes sure the login exists in that applet’s tenant, and the tenant a grant lands in is taken from the applet-to-catalogue link row rather than from the tenant you were inviting into. A catalogue whose rows point at more than one tenant therefore admits the person to every one of them in a single invitation. Compose catalogues deliberately, and check the tenant on each row before you use one as the target of an invitation — this is the concrete reason behind the advice not to hand out a catalogue you have not looked inside.

Fields

The store has no create or edit form. These are the fields it displays and the one field it accepts.

Applet card (all three listings)

On the Public and Private tabs the card’s title is the applet’s name from the registry, read afresh on every load; a catalogue cannot rename an applet, so a rename in the Developer SysAdmin Applet reaches those cards at once.

Applet detail screen

Review dialog

Lifecycle and effects

The Applet Store is a utility applet. It posts no journals, moves no stock and writes nothing to any tenant ledger. Everything it changes lives in the platform (master) database.

Three consequences worth knowing:

• Uninstall is reversible and destroys nothing. It deletes the link between your login and the applet. Reinstalling from the same catalogue entry gives you the applet back; the data the applet holds in the tenant is untouched either way.
• Install All is not idempotent across catalogues. It skips anything already installed and anything blocked, so pressing it twice is safe, but it installs only what is on screen — on the Private tab that is the catalogues loaded so far, not all of them.
• An applet already installed from one catalogue cannot be installed again from another. The listing marks such a card as blocked and refuses the click, with the tooltip This applet has been installed in another catalog!

There are no statuses to manage in this applet. An installed link is either present and ACTIVE or gone.

Related applets

• Developer SysAdmin Applet — registers the applet and everything the store displays about it. If a listing looks wrong, the record behind it is edited there.
• Tenant Admin Applet — builds catalogues, decides who sees a private one, and installs applets in bulk for other users in the tenant. It is the administrator’s counterpart to this user-facing screen.

Troubleshooting

Related documentation