ownloads Documentation Centre!Controlled Access to Categories and Downloads
Introduction
Note: This is a long and detailed article that may require patience!!An example of the structure of a membership type arrangement is shown in Limited Access - Membership Example (opens in a new window/tab).In these notes 'Downloads' when spelt with a capital 'D' means the colllection of information such as descriptions, previews, images and so on as well as the file that is to be downloaded. Words such as 'download', 'downloads', ' downloading' and similar spelt with a lower case 'd' generally refer to the actual task of transfering the file from the server to the local device.Also the term 'downloaders' group relates to those Joomla! User Groups that only have the abilty to download Downloads. Similarly 'uploaders' group means those User Groups that have permission to create, edit and download, and maybe delete, Downloads.
The main objective of this article is to explain how a combination of using the Joomla! Permissions and View Access Levels are able to control which user groups can just download and which user groups can download, create new Downloads and edit existing Downloads.
Another objective is to avoid error messages that tell the user something like “You do not have permission….”
However before beginning it is useful to get some context about Joomla! User Groups as it is through the User Groups that permissions are applied. The permissions do not 'belong' to the User Group but they belong to the articles, the Categories, the Downloads, and similar 'content'.
So each jDownloads Category and each jDownload Download will have a user group setup where permissions may be inherited, allowed or denied. It would clearly be an onerous task to have to set each jDownloads Category and Download individually. The core Joomla! strategy is that Permissions 'cascade' down, thus the default permissions are Inherited. So if there is a top level jDownloads category with sub categories and each sub category has multiple Downloads then unless it is modified the permissions in the top category will flow down to all the sub categories and their Downloads as illustrated opposite. Note If you change a permission you need to do a Save or Save & Close for the 'cascading' to occur.
Background Notes
Each user group, except Public, has a parent and whether positively set or not then any user will also belong to the Parent user group, and to its parent and so on. That is all users except those only in the Public group will belong to multiple groups because of this implicit relationship with the parent group, the grand parent and so on. As well as this implicit membership users may be joined explicitly to multiple other groups.It is perhaps useful to think of User Groups as giving specific abilities. The names of the base User Groups in Joomla! imply that through their name.
So the objective here is to have User Groups that relate to jDownloads. So we may need Downloader and Uploader user groups.
Then if we have a user who will publish regular Joomla! articles and will also create/edit Downloads then that user would be set explicitly as a member of both the Publisher User Group for access to ceate and edit articles, and to the Uploader User Group to allow creating and editing Downloads.
If the only need is to Download then the user would belong to the Downloaders User Group. In many cases of course there is no need to have an explicit Downloader User Group as the Public or Registered User Group is sufficient.
As well as Categories and Downloads having permissions setup for each user group, the jDownloads component itself also has permission setups for each user group. These act as the 'default' settings for the top level categories. These Component permissions are accessible though the Options button on the jDownloads Control page. In all but the simplest cases it is best to leave the Component permissions untouched as 'Inherited'. Note that during the initial installation of jDownloads then Download permission is given initially to the Public user groups. This is necessary initially as at that time Categories and Downloads do not exist, and it provides an instant means that users may download. However in any more sophisticated scheme it is best to reset the jDownloads Component Download permission to Inherited.
Also we would strongly caution against setting any permission to Deny. This cannot be overridden lower down the permission chain. Generally if you need to use Deny then the probability is that you have a poor arrangement of your categories and Downloads!
When dealing with Permissions it is helpful to look at the relationship between the various User Groups (UGs). The picture opposite illustrates the relationships for the standard UGs.
The root UG is the Public Tree. The Public UG has 4 sons (Guest, Manager, Registered and Super Users), 2 Grandsons (Administrator & Author), 1 Great-Grandson (Editor) and 1 Great-Great-Grandson (Publisher). If the Public UG has a particular permission then this is inherited by all the User Groups.
Note that the root of the permissions is the Public UG, not the Superusers UG.
The Super Users UG is actually a 'non standard' UG as it has permissions for all 'actions'. So please remember that logging into the Front End as a Super User is not what a user in another UG would see, that is testing as Super User in the Front End is NOT a good idea because it is not a realistic test.
If we create a Downloader UG with Registered as its Parent UG then it will inherit the permissions that are in the Registered UG and in the Public UG.
It is most important to remember that each Category, Sub-Category and Download has it own set of pemissions. So if in one top level Category, called say PublicCat, we set Download permission to Allowed in its PublicUG then that permission will cascade down any sub category tree and onto the Downloads themselves. That means any user can download any Download from that tree which started at category PublicCat.
If we also need something different for Members, that is logged in users, we could create a Category called say MemberCat. For MemberCat we would set the Registered UG to have Allowed for the Download permission. Again the permission would cascade down the sub cat tree and to the Downloads belonging in that tree starting at MemberCat.
Examples Summary
There are four examples below that will cover the most common arrangements.
- Basic Download Scheme:
- Public can download,
- Registered users can upload and download.
- An Enhanced Download Scheme:
- Registered group can download,
- Another User Group, the 'uploaders', can create and edit Downloads as well as being able to download,
- Variant 1: No public view of downloads,
- Variant 2: Public can view Downloads but cannot actually download.
- An Extended Download Scheme:
- Public User Group can download some Downloads,
- Registered User Group can download all Downloads,
- Another User Group, the 'uploaders', can create and edit Downloads as well as being able to download,
- Extensive multi department arrangement where each department has multiple sections:
- user groups that can only download from their own section of their department,
- an uploader group that can create, edit and download for all sections in their own department
Further notes
Before looking at the examples here are some further notes that may help your understanding.
- Access levels determine which user groups can see what. Permissions apply to User Groups and control what can or cannot be done. So in order to download for example then the Download itself needs Download permission for that user group. Similarly so do the relevant Categories. As in Joomla!, jDownloads passes Permissions down, 'cascades', from a parent Category to its child Categories and Downloads. When creating a top level Category the permissions are taken from the Component permissions.
- The jDownloads Component Permissions are readily available by using the toolbar Options button, which looks something like
on the jDownloads Control page and the other principle pages. - Except for the very simplest schemes, Permissions are best set at the top level categories, that is set the Component permissions to Inherit for all User Groups.
- Another key factor to keep in mind is that User Groups are arranged in a tree-like structure. The Public Group is the common root. There are four basic chains
- Public - Manager - Administrator
- Public- Super Admin
- Public - Registered - Author - Editor - Publisher
- Public - Guest
- The Super Admin is an exception to the following as the Super Admin group always has permission to do anything.
- There are a few simple 'guide-lines' or 'rules' derived from experience that one should observe when setting up Permissions for jDowloads Categories and Downloads as follows.
- Never use the Deny permission, if you find you need to use it the it is almost certain something is wrong!!.
- For those cases where a user has to logon to download then:
- only use Registered as the Parent of any downloader User Group (UG);
- if you want a user to be able to say publish regular joomla! articles and to be able to download then join them to the Publisher UG and to the relevant downloader UG, do not try to 'combine' - just use separate UGs.
- Except for the simplest of situations set the Component download permissions to Inherited for all UGs, except Super User of course.
- The parent of an 'uploader' UG could be either Registered or the relevant 'downloader' UG.
- Wherever possible separate different classes of Downloads into individual Top level categories. There may of course be multiple sub categories.
- You should never need to set permissions directly on a Download.
- If you get a problem then start again by using the Permissions Reset tools.(opens in a new window/tab)
- As an illustration suppose we have a user group called "Class-A" whose parent class is the Registered group, and another group called "Teacher-A" whose Parent group is "Class-A". The inclusive nature of user groups is that any user who is a member of Class-A is also a member of the Registered and the Public groups, even if the Public and Registered groups are not 'ticked' when allocating a user to Class-A. Similarly a member of the Teacher-A group is automatically a member of the Public, Registered, and Class-A User Groups. That would mean that if we were to specifically 'deny' download privileges to the Public group, or to the Registered group, then no one in Class-A or Teacher-A would be able to download. This is because once denied then a permission cannot be regained by a subsequent child group.If we wish to allow anyone to download then clearly all that needs to be done is to set the Public group to allow Download. An alternative in this case would be to set the Component download permission for the Public group to Allow.
- Important When setting up user groups and their permissions thought has to be given to the effect elsewhere on the site. If your site has been set up in the 'usual' manner, then if the 'uploader' group has say Publisher as its parent category then it will probably have the unintended consequence that 'uploaders' may also be able to edit articles and the like elsewhere on your site. This may not be what is intended. It is recommended then that 'uploader' groups and downloader groups, should be setup with Registered as the Parent group.
-
If a user belongs to a user group that has:
- Download permission then the
button will be visible for each Download; - Edit permission then the edit pencil,
, will appear for each download. Clicking on the pencil will open up the Edit Upload form; Note Edit permission allows deletion of the file associated with the Download but not the deletion of the Download itself. - Create permission will show the
symbols. Clicking on either the up-arrow symbol or Add will open the Create Download form. - Delete permission allows the user to delete of all parts of the Download as setup in the Configuration - there are option to allow retention of images and audio and video previews.
- Download permission then the
- For 'uploader' UGs remember to go to the User Groups Settings to set up a non zero Ranking and decide which options tjat UG will see in the Create/Edit form on the Front End. You may for instance constrain them to just one category.
- Where users belong to multiple 'uploader' user groups it is important to set the Ranking in the jDownloads User Groups Settings appropriately. Specifically if a user belongs to more than one group jDownloads uses the group in that set which has the highest ranking to select the User Group Settings that should be used.
- The other User Groups Settings are particularly important for the ' uploaders' group as many of the settings are concerned with what questions the upload form will ask. Users in groups that are not uploaders can have performance criteria set say limiting the number of downloads in a certain period. Note also that jDownloads ignores user groups with zero ranking when assessing which set of user group settings should be used,
- If you find that you have to set a permission to 'denied' it is probable that your scheme is structurally fragile, and that you have not made proper use of View Access Levels to effectively prevent access.
The Simplest Download Access Scheme
- Public can download
- Another User Group, the 'uploaders', can create and edit uploads as well as being able to download.
In this scheme all the Downloads are publically available.
The Component Permission for Download in the Public Group is set as Allowed. Leave all others as Inherited. These setting will then propagate through all categories and Downloads for all groups. (recall from above that the Component Permissions are accessible by using the Options button on the jDownloads control panel or the User Groups Settings page.)
As a word of caution beware of setting any Public permission as Denied as that will lock out everyone, except a super-admin, from the associated action.
The Registered group could for any 'uploader' in this very simple case. This is particularly so because when a user is created Joomla! automatically puts them in the Registered group.
However it is probably best to have a separate UG whose Parent is the Registered UG. So set the Component Registered Permissions for Create, Edit and Edit Own to Allowed for whichever UG is to be the front end Uploader UG.
Setting up a specific Uploader User Group is discussed in the Simple Restricted Access Download Scheme below.
If you decide to allow 'uploaders' to be able to delete entire Downloads then also set Delete permission to Allowed. The Edit permission allows deleting of associated pictures or previews and the deletion of the downloadable file itself so they can be changed but not the entire Download.
Download permission can be left as Inherited as that permission will propagate through from the Public group as set above.
To repeat, these Permissions will propagate to all the categories, sub categories and so on, and to all the downloads. Basically if your site just uses this very simple scheme you have no further need to be concerned about the Permissions as they will now look after themselves.
It is worthwhile looking at the User Group Settings as you can customise what questions an 'uploader' will have to specify, and if you wish you can set your own site specific questions.
If you are only using the Registered group as the 'uploader' group, jDownloads will already have automatically sets that group with a non-zero ranking but if you use the more sensible approach of a separately identifiable uploader UG then you do need to set user group ranking to a positive non zero value in the User Groups Settings.
However you do need to be aware of the View Access Levels for the 'uploaders' from the front end. Creating or editing a Download is through the jDownloads menu item type 'Create Download'.
The Access needs to be set to a View Level Group which has the Registered or the specific 'uploader User Group as a member.
This avoid users having messages such as 'You do not have permission to ...'
This then ensures that only members of that View Group will see the menu item. In this example the View Access Group is called ViewRegCats.
A Simple Restricted Access Download Scheme
- Registered User Group can download
- Another User Group, the 'uploaders', can create and edit uploads as well as being able to download.
To save repetition please read the 'The Simplest Download Access Scheme' above as many aspects are similar. But note that you should leave all Component permissions as 'inherited'.
Because Joomla! automatically allocates new users to the Registered group then that will be our user group that will be able to download.
First create a new User Group called 'reg-uploaders' with the User Manager and set the Registered Group as its parent. This group will be for the 'uploaders', and because it has a parent of Registered then unless it has been deliberately changed elsewhere then uploaders will not have permissions to create or edit regular Joomla! articles and other such material.
Next create two new View Access Levels:- ViewDownloaders with the Registered Group as it only member (actually there is a Registered View Access Level already which will serve the same pupose);
- ViewRegUploaders with just the reg-uploaders as its only member. This is used in the "Create A Download" menu item so that the menu is only seen by the 'uploaders'. Note the 'uploaders' are implied members of the Registered group so they will also see the other menu items.
Any menu item that is not concerned with creating or editing a Download, such as a List All Categories type for example, should be set to an Access of ViewDownloaders. Any menu item that is for creating or editing a Download, namely the Create Download type, should be set to an Access of ViewRegUploaders. This avoids the 'You do not have permission' type of error.
|
In the 'Simplest' example above it was the jDownloads Component permissions that were changed. Rather than do that it is better in the long term with these more advanced schemes to change the permissions of the top level Categories as this leads to a more flexible and extendable and maintainable scheme. Set the permissions in the top level categories to those shown opposite. This is slightly more effort than just setting those in the Component permissions as it needs to be done to every top level category. Note you may decide to allow uploaders to completely delete a Download in which case set the Delete permission to allowed for the reg-uploaders group. |
 |
 |
|
In doing this it is worth remembering that the Permissions belong to each Category. So we go to the top level Categories and set the Permissions for for just the two relevant UGs. |
||
|
Set the View Access Level on each category and download to Registered. When creating a new category or download then the View Access Level will be taken from its parent when it is saved. Note that this only happens if the Access has not been changed so it is suggested that an initial Save is made at the earliest opportunity. Normally in jDownloads Access levels are inherited from the parent category to the child subCategory or the Download as they are created. However some times new a sub category is created in the middle of the chain so that the View Access levels are disturbed. Rather than have to change them individually, which would be tiresome with a large number, it is easy to set multiple downloads or categories in a single operation. See Batch Processing (opens in a new window/tab) for more details. This is obviously useful for both existing sets of downloads and if you also do bulk transfers using ftp or similar. |
 |
|
An Extended Access Download
- Public User Group Can download some Downloads
- Registered User Group can download all Downloads
- Another User Group, the 'uploaders', can create and edit Downloads as well as being able to download.
This scheme, which is a combination of the two previous schemes, some Downloads may be downloaded by Public users, and an extended set may be downloaded by logged on users in the Registered group. This example is a simplified version by where there are only two root categories, one called 'PublicDownloads' and the other one called 'LoggedOnDownloads'. Clearly there could be many more root categories and these would be treated the same as one or other of the two types.
As with the Simple Restricted Access Scheme create a new User Group called 'reg-uploaders' with the User Manager, setting its parent group to Registered. This group will be for the 'uploaders'.and should be set with Create and Edit permissions as Allowed. It will Inherit the Download permission from the Registered group.
Again as perviously create a new View Access Level:
- ViewRegUploaders with just the reg-uploaders as its only member. This is used in the "Create A Download" menu item so that the menu is only seen by the appropriate users.
For this example create two root categories, one called say 'PublicDownloads' and the other one called 'LoggedOnDownloads'. .Set the Download permission of the
- Public group in the 'PublicDownloads' category as Allowed,
- Registered group in the 'LoggedOnDownloads'.category as Allowed.
|
As shown opposite set the View Access Level on each category, sub category and so on, and on each download In the PublicDownloads tree to Public. Similarly for the LoggedOnDownloads tree set Access to Registered. For this example the two top level categories were simply renamed. When creating a new category or download then the View Access Level will be taken from its parent when it is saved. Note that this only happens if the Access has not been changed so it is suggested that an initial Save is made at the earliest opportunity. As noted earlier Access levels do not pass from parent to child automatically in Joomla!. Rather than have to change them individually, which would be tiresome with a large number, it is easy to set multiple downloads or categories in a single operation. See Batch Processing (opens in a new window/tab) for more details. This is obviously useful for both existing sets of downloads and if you also do bulk transfers using ftp or similar. |
 |
An extensive multi department scheme
In this example the situation is an enterprise that has several Departments. Each Department may have one or more Sections. Each Department is to be separate, that is the supvervisor level can create, edit and download their own departmental Downloads but they cannot access or even see those from any other Department. Further each Section in a Department is only allowed to see and download its own Downloads.
Here the people in the supervisor groups are refered to as a Foreman, and each person in a section is referred to as a Worker.
Furthermore each user is to see only a single menu item with the name 'Downloads' in order to simplify the documentation.
For simplicity of naming each department is know by a letter such as 'A' and each section is known by a numerical code such as '1'. So a Foreman in department A would belong to a user group called foremenA, and a Worker in section 1 of department A would belong to a user group workersA1. These are shown below for two departments each with two sections.
There are three stages to the setup
- Joomla! User Groups and Access levels
- Categories with Permissions and View Access Levels
- Menus
User Groups and Access levels
|
The first sub-stage is setting up the Joomla! User Groups User Groups All have Registered as their Parent foremenA Department A supervisor level users |
 |
||||||||||||||||||||||||||||||||||||||||||
|
The second sub-stage is setting up the Joomla! View Access Levels. As shown below under Usage half of the Access Levels, those with multiple groups, are used with Categories whilst the other half, those with a single group, are used with the menus. The naming convention is hopefully self evident, view is appended to each name to emphasise it is what users in a group can see. |
|||||||||||||||||||||||||||||||||||||||||||
|
 |
||||||||||||||||||||||||||||||||||||||||||
Categories with Permissions and View Access Levels
| The category setup is quite simple and is a direct reflection of the organisation. The arrangement will allow the supervisors to see the contents of their top level category, all the sub categories and all the Downloads in ther Department. The Employees will only see their own sub category and its Downloads. Note that in order to view their own section's sub category and its Downloads it is necessary that the sections have view access to the Department top level category. They will have not of course have any permissions relating to their top level categoy. The menu scheme will take them directly to their own sub category and its Downloads as shown later. | ||
| Categories TopA ................................................................ |— SubCatA1 ................................................ |— SubCatA2 ................................................ TopB ................................................................ |— SubCatB1 ................................................ |— SubCatB2 ............................................... |
View Access Levels FAandWA1andWA2view WA1andFAview WA2andFAview FBandWB1andWB2view WB1andFBview WB2andFBviewn |
 |
The next step is setting up the permissions where the objectives are to allow:
- TopA to hold all the Downloads that only members of usergroup foremanA can action (download, create & edit);
- SubCatA1 to hold all the Downloads that only members of usergroups foremanA(download, create & edit) and workersA1 (download) can action;
- SubCatA2 to hold all the Downloads that only members of usergroups foremanA(download, create & edit) and workersA2 (download)can action.
Usually Permissions are only required on the top level and first sub level categories as the permissions will cascade down to the Downloads. That is after setting up we do not have to be concerned with setting permissions on Downloads individually. In special circumstances different permissions could be set on intermediate sub categories or on Downloads themselves.
Also permissions could be set at the Component Level by using the Options button on the jDownloads Control page or the one on the jDownloads User Groups Settings page. Using the Component permissions tends to be less flexible if there are other arrangement outside our departmental structure. So in this example the permissions will only be set on the categories.
This means Setting theTop level Categories and the first sub category levels Permissions. All Downloads will inherit the neccessary permissions
|
Category: TopA for User Group: foremenA
Note If the Supervisors (foremen groups) are allowed to delete then set the Delete pemission to Allowed Category: SubCatA1 for User Group: workersA1
Category: SubCatA2 for User Group: workersA2
Leave all other permissions as Inherited Now repeat for all the other Departments and Sections. |
 |
Menu Setup
The objective with the menus is that only one 'Download' menu link is shown when a user logs in. This is simply controlled by the relevant Access Level.
Menus
Name Type Menu Title Access Level Category selected Only Visible when member of
user group below is Logged In
List All A Categories jDownloads » List All Categories (Default) Downloads FAonly-view TopA foremenA
List SubCatA1 jDownloads » Single Category Downloads WA1only-view SubCatA1 workersA1
List SubCatA2 jDownloads » Single Category Downloads WA2only-view SubCatA2 workersA2
Note: The alias for each menu item has to be modified, one cannot use auto generate.
ColinM July 2014, modified December 2014, January 2015 & February 2015, October 2017, April 2022