Permissions - an initial view
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.
The Root Permissions
(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 except where they have been explicitly in the Calculated Setting column or Inherited.
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.
User Group Inheritance
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.
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
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.
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
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.
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.
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.
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.
In this simple example two top level categories were created, one called 'Public Downloads' and the other 'LoggedOnDownloads'.
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.
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!
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.".
Frontend Create & Edit Permissions
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.
Recovery (or StartAgain!)
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 and 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