Skip to main content

7. Access Levels: Category, Release, and Item are independent

ARS lets you set a Joomla View Access Level on the Category, the Release, and the Item — each one separately, not inherited automatically. This is actually the right design for a commercial product, once you understand it: you generally want the Category and Release browsable at Public (so people can see your product exists, read changelogs, and find you via search — good for discovery and SEO), while the Item — the actual downloadable file — is what should carry the restricted Access Level.

LEVELRECOMMENDED ACCESSWHY
Category Public Lets anyone browse and discover the product page
Release Public Lets anyone see version history / changelogs
Item Registered (or your licensed-users group) Gates the actual file download
A FALSE NEGATIVE YOU WILL ABSOLUTELY HITIf you're testing this while logged into any account that already has sufficient View Access — a Super User in the backend, or simply a front-end customer account with an active subscription — restricted downloads will succeed regardless of Access Level or Download ID. Joomla's access check is evaluated against whichever user the current session belongs to, full stop; it doesn't care whether that session came from logging into the backend or the storefront's front-end login. A logged-in customer checking their own account credentials is just as capable of masking a broken restriction as a Super User session is. This will make a broken restriction look like it's working perfectly. Always test the unauthenticated path in a private/incognito browser window with no session at all — front-end or back-end.

One more detail worth knowing before you rely on it: per Akeeba's own confirmation, a correctly issued Download ID authenticates an unlogged-in request to a Registered-restricted item on its own, natively — you don't need a logged-in browser session for it to work, because it's designed specifically for Joomla's own background update-check process, which never has one.