Permissions - an initial view

This article is a first look at Permissions.  It provides a broad overview that will help with the detailed use of permissions.

The article includes three simple examples:
  1. a public site where all Downloads are available for downloading;
  2. a private site were users members, that is logging in is required;
  3. a mixed site with some Downloads publically available and others only available to logged in members.

It is useful here to first distinguish between Access Levels and Permissions.  Briefly Access Levels determine what you are able to see on the front end so if you can see a category or a Download then you have Access.  Permissions determine what you can do, for example download, edit and so on.

If you have upgraded your site from Joomla 3.9 to Joomla 4 then all Category and Download permission settings will have been copied as well.
V4 initial note

The Root Permissions

The root or Component permissions is where the permissions begin in a new site. If you have a site where all Downloads are to be publically available the leaving the Download permissions in the Root is fine.  But if you need to restrict permissions to specific User Groups such as Registered users then you will need to set the Download permission in the Root to 'Inherited'.  Never use 'deny' permission .

A simple way of seeing the root Permissions for the jDownloads component is to go to the button control panel and then click on the button options button near top right and then click on the V4 button permissions tab.

Control Panel
An alternative method is to click on the button change default shown with the initial note above.
This set of permissions are often referred to as the Component Permissions or root permissions.  Before looking further into permissions it is most important to understand that permissions are inherited in two ways:
(1) from the root of the Public user group and through the child user groups as noted below;
(2) from the top level categories, through the sub categories eventually to the Downloads as illustrated later.

Another important aspect of understanding the way permissions work is that the system assumes permission is not allowed, that is permissions have to be positively allowed.  This is seen below where the basic Calculated permissions in the root are not allowed inherited except where they have been explicitly allowed in the Calculated Setting column or Inherited.

This shows the jDownloads root or Component  Permissions; these are the 'initial' starting setup for the Public user group when jDownloads is first installed. 

The three top and the bottom two items, which have been highlighted, are only available at the root level.  They are useful if you are allowing backend access to a usergroup.

The other six permissions provide the basis of what the Categories and Downloads will inherit.  These are the significant items for what is permitted in the frontend.

The permissions shown here are those automatically set up by jDownloads when it is installed for the first time.

This means after initially installing jDownloads then by default all Downloads are publically downloadable.

This may not be desirable and more details are given later in this article.
root permissions

User Group Inheritance

The relationship and inheritance between the various usergroups (UGs) is shown opposite. 

Note that the Public UG is the top level one.  So any permission set in the Public UG is inherited by all the other UGs.  The Public UG inherits its initial setting from the Root.

Having the UGs arranged this way means for instance that Publisher may have more permissions than Editor, which in turn may have more permissions than Author.  This is because, for example, the Publish user group inherits the settings of Editor, Author, Registered and Public user groups.

One additional UG, the UploaderUG, has been created.  It is positioned as a child of Registered and may have appropriate permissions relating to Downloads without necessarily interferring with permissions in the Author or other permission 'chains'.

Actually the Super User group is basically 'outside' the normal chain as it always has all permission.
groups tree

In this and other articles, it this UploaderUG usergroup that will allow creating and editing of Downloads from the frontend.

To repeat, as a general rule it is advisable to introduce separate user groups to provide any required facilities for jDownloads activities rather than attempt to include them in the existing Author - Editor - Publisher usergroups.  Users who Author articles may be different users from those who create or edit Downloads.  If a particular user will be editing articles and creating Downloads it is much simpler, and a cleaner design, to make that user a member of both user groups.

That is keep it simple!

Categories And Downloads Inheritance

Categories, Subcategories and Downloads form a tree structure of the way permissions reach Downloads as illustrated opposite.

In this very simple example the Root (component permissions) is followed by two ‘main’ categories, each with two sub categories, and each sub-category has three downloads.

Of course we can have sub-sub-categories and so on.  Also we can have Downloads at any level except at the root.
Folders tree
The actual structure of categories and Downloads may be, and usually is, much more complex than the one illustrated here.

This tree structure is the way a regular file system is organised; it is also the way the download files are stored in directories.  One may think of permissions cascading down the tree.  If a permission is set to Allowed in say a top level Category then that permission will cascade down the tree to the bottom 'leaves', that is to the Downloads.

More significantly in the present context it represents the way in which new  subcategories and downloads get their default Permissions. That is new sub categories and downloads get their default Permissions for each user group from their immediate parent.

Note on Deny

As is usual for permission schemes, the Joomla Permissions scheme is based upon ‘not allowed’.  If a Permission as shown in the Calculated Permissions column as not allowed inherited at one level then it may be regained at a subsequent child level by simply setting an allowed permission.  This Allow will cascade down the tree and be shown in subsequent 'leaves' as allowed inherited in the Calculated Permissions column. 

The situation is totally different if a particular permission is 'denied' then that permission cannot be revoked in susequent layers further downstream.  For example if ‘Download’ access at the root level is denied, then that group cannot execute a download of anything!   That is Download or any other permission has to be allowed somewhere in the permission chain. If you have a Deny then Allow cannot be set when saved.  If one were to set Deny on Download permission in the  for the Public group root then no one can Download except a super-user.

Basically when setting up permissions for jDownloads never use Deny as it is most likely to have unwanted and unexpected side effects.


As indicated previously most sites may be put into one of three types in terms of permissions.  These are noted below.
1. Any user may  download any file, this is a public site.
2. Only logged on users may download a file, this is a private site.
3. Some files are publically downloadable and others are only downloadable by logged on users, this is a mixed site.

Public Site

A Public site is the simplest permissions set up.

One just sets the Download perrmission of the Public user group in the root permissions to 'Allowed' as shown opposite.

Actually this is the default setting on the first time install of jDownloads.

If you change any permission it is essential to do a Save, or Save & Close, as the permissions are propogated whilst the Save occurs.
root permissions02

Private Site

A Private site is simarly simple to setup and again just needs setting the root permissions. 

In this case the Public user group Download permission is left ator reset to inherited.

The Registered user group is selected and the Download permission set to Allowed. 

In this example the image shown opposite is before the Save so the green tick is present.
root permissions03

Mixed Site

For a mixed site we set the root permissions inherited.  The first step in any arrangement is to change the root Download permission for the Public group to 'inherited'. So at that time no one except a Super User can download.

In this simple example two top level categories were created, one called 'Public Downloads' and the other 'LoggedOnDownloads'.

root permissions04
Note that the Access level for the LoggedOnDownloads is set to Public. This means that when the permissions have been set up public users will see the Downloads but will not be able to download anything from them.  So this could be used to 'promote' membership.

If you do not wish public users to see the 'LoggedOnDownloads' then set the Access to Registered.  You might do this as an interim whilst the permissions are being set up.

The next step is setting the Download permission of the Public groups of category 'Public Downloads' to Allowed as indicated opposite.

After Saving the Permissions, this will propogate through all the subcategories and to the Downloads   members of the public will now be able to download those Downloads in the Public- Downloads' category and its subcategories.
root permissions05

For the 'LoggedOnDownloads' category the first step is to check that the Public usergroup does not have Download permission.

If it is set it probably means you have left some permission in the root permissions or maybe already set in the Category!
root permissions06

Next set the Download permission of the Registered usergroup to 'Allowed ' and Save to propagate.

Only Registered users will now be able to download from the Downloads in the 'LoggedOnDownloads' category tree.

A typical message shown to a public or guest user if Access is public is: "Only registered and logged in users can download files from this category.".
root permissions07

Frontend Create & Edit Permissions

There is one other set of permissions that is useful to set in the root

This is for the usergroup that will be allowed to create and edit Downloads from the frontend.

In this example it is the uploaderUG which is setup as shown.  Generally my personal preference is that Downloads cannot be Deleted from the front end.

Note that changing the downloadable file is part of the editing abilities.

root permissions08
Also note that Download permision has not been given as it will be inherited from either the Public or Registered usergroups, but it does no harm if Download permission is also allowed here.

Recovery (or StartAgain!)

Sometimes, particularly when first setting up permissions, it may happen that the permissions are not working as required. Or they may be getting seemingly over complicated.

There is a way out!  First set up the root permissions for each User Group as required. Then go to the jD Control Panel and Select Tools.

There you will find button reset downloads and button reset cats buttons. Use these in turn and all is back to a clean situation.

For more details see the article Permissions resetting tools. (opens in a new window/tab)

ColinM, March 2020, modified April 2022, June 2023

Print Email

We use cookies

We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.