Controlled Access to Categories and Downloads (Permissions & Access Levels)

Various examples of Permissions and View Access Levels applied to Categories and Downloads. Revised

Controlled Access to Categories and Downloads – some examples.

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.

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 multiplegroups 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 the Publisher User Group for access to ceate and edit article, 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 Pbulic 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 initial installation it is recommended that  Download permission is given initially to either the Public or the Registered 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 set the Component permissions 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!  There are two sets of inheritances working ate the same time: one is through the Categories, sub cats and to the Downloads; the other set is through the User Groups themseves from the user group to its parents and Grand Parents and so on.

ContAccess05A

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.

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 rember 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 the Category PublicCat.

 UG tree01
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.

There are four examples below that will cover the most common arrangements.

  1. The Simplest Download Access Scheme -
    • Public can download,
    • Registered users can upload and download.
  2. A Simple Access 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.
  3. An Extended Access 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,
  4. An 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

Before looking at the examples here are some further background notes that may help your understanding. 

  1. 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.
  2. The jDownloads Component Permissions are readily available by using the toolbar Options  button, which looks something like  Access01A or Access01B dependant on version, on either the jDownloads Control page or the User Group Settings page.
  3. 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.
  4. Another key factor to keep in mind is that  in Joomla! User Groups are treated in an inclusive manner.  The user groups are arranged in a tree-like manner.  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
  5. The Super Admin is an exception to the following as the Super Admin group always has permission to do anything.
  6. 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.
    1. Never use the Deny permission, if you find you need to use it the it is almost certain something is wrong!!.
    2. For those cases where a user has to logon to download then:
      1. only use Registered as the Parent of any downloader User Group (UG);
      2. 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.
    3. Except for the simplest of situations set the Component download permissions to Inherited for all UGs, except Super User of course.
    4. The parent of an  'uploader' UG could be either Registered or the relevant 'downloader' UG.
    5. Wherever possible separate different classes of Downloads into individual Top level categories.  There may of course be multiple sub categories.
    6. You should never need to set permissions directly on a Download.
    7. If you get a problem then start again by using the Permissions Reset tools - http://www.jdownloads.net/documentations/item/using-permission-reset-tools
  7. 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.
  8. 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.
  9. If a user belongs to a user group that has:

    • Download permission then the Access33B button will be visible for each Download;
    • Edit permission then the edit pencil,  Access33C, 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 Access33symbols.  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.
  10. 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.
  11. 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.  jDownloads does not use the Rank value to select which set of permissions or access levels apply.
  12. The for  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 download 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,
  13. 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.

This scheme is one where all the downloads are publically available. 

In this case set the  Component Permissions for the Public Group with Download as Allowed and leave all others as Inherited.  The Download Allow 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.

Note: This is the only scheme that sets the Component permissions  In all other schemes all of the Component permissions are left as 'inherited'.

Access04A

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.

Access04C

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;  its only member group is the appropriate User Group.

We are now done.

view access01

  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.

In this scheme downloading is restricted to logged on users so ensure all  users belong to the Registered group. This is actually the Joomla! default when a new user is created so it is easy to manage. Leave the Download permission of the Public group in the Component permissions as Inherited, and set the Download permission of the Registered group in the root Categories as Allowed. Never set any Public permission as Denied as that will lock out everyone from the associated action.

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 remebering 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.

Access30 Access31A

As explained earlier in this article jDownloads need to know which user group to use, and for this it uses the Ranking value set in User Groups Settings.  This is particularly so for the 'uploaders' who will belong to three user groups: Public;Registered; and reg-uploader.  Clearly reg-uploader is the most important group for the uploaders so set a ranking value greater than that of either the Public group (ranking=1) or of the Registered group (ranking=20).  So a value such as 23 would be fine.  If you leave the ranking value for reg-uploaders to its default of zero then it will be ignored by jDownloads.

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 Rapidly setting View Access Levels of multiple Categories and Downloads for more details. This is obviously useful for both existing sets of downloads and if you also do bulk transfers using ftp or similar.

 Access32A  

An Extended Access 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.

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 Rapidly setting View Access Levels of multiple Categories and Downloads for more details. This is obviously useful for both existing sets of downloads and if you also do bulk transfers using ftp or similar. 

 

 

 

The images below indicate what will be seen dependent on login.  Here we have some Registered users and a user called 'j32-uploader-reg' who is a member of the reg-uploaders user group.

Access34A
 Access35A
Access35BAccess35C

 

 An extensive multi department arrangement where each department has multiple sections

 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

  1. Joomla! User Groups and Access levels
  2. Categories with Permissions and View Access Levels
  3. Menus

User Groups and Viewing Access Levels setup

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 able to create, edit and download in all sections of their department
    workersA1           Department A Employees in Section 1
    workersA2           Department A Employees in Section 2
    
    foremenB            repeat of above for User Groups for Department B
    workersB1
    workersB2

ParallelAccess01  

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.

 
Access Levels Member Groups Usage
WA1andFAview workersA1, foremenA Used in jDownloads Categories
WA2andFAview workersA2, foremenA Used in jDownloads Categories
FAandWA1andWA2view foremenA, workersA1, workersA2 Used in jDownloads Categories
FAonly-view foremenA Used in Menu items
WA1only-view workersA1 Used in Menu items
WA2only-view workersA2 Used in Menu items
   
FBandWB1andWB2view repeat of above for Access Levels for Department B
WB1andFBview    
WB2andFBview    
FBonly-view    
WB1only-view    
WB2only-view    
ParallelAccess02

jDownloads Category setup

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
ParallelAccess03

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

Permission type      Create     
Delete         Edit      
Edit State    Edit Own   
 Download 
[Select New Settings] Allowed Inherited  Allowed  Inherited Allowed Allowed
[Calculated Settings] Allowed  Not Allowed  Allowed  Not Allowed  Allowed Allowed

Note If the Supervisors (foremen groups) are allowed to delete then set the Delete pemission to Allowed

Category: SubCatA1     for User Group: workersA1

Permission type  Create 
Delete    Edit  
Edit State Edit Own  Download 
[Select New Settings] Inherited Inherited  Inherited Inherited Inherited Allowed
[Calculated Settings]  Not Allowed   Not Allowed   Not Allowed   Not Allowed   Not Allowed  Allowed

Category: SubCatA2     for User Group: workersA2

Permission type  Create 
Delete    Edit  
Edit State Edit Own  Download 
[Select New Settings] Inherited Inherited  Inherited Inherited Inherited Allowed
[Calculated Settings]  Not Allowed   Not Allowed   Not Allowed   Not Allowed   Not Allowed  Allowed

Leave all other permissions as Inherited

Now repeat for all the other Departments and Sections.

ParallelAccess04 

 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.

Colin Mercer July 2014, modified December 2014, January 2015 & February 2015, October 2017

  • Wednesday, 30 July 2014