{% extends "admin_base.html" %} {% block copyright %} {% endblock %} {% set body_id = 'folder_permissions' %} {% set page_heading = 'Folder permissions' %} {% block body %} {{ super() }} {% if err_msg %}
{{ err_msg|newlines }}
{% else %} {% set old_access = current_permissions.access if current_permissions else FolderPermission.ACCESS_NONE %} {# It is checked for here, but note that this page does not expect to receive current_permissions where the group ID is different. The UI may in fact fall back to the Public group if there are no permissions defined for group Foo, however this would make the admin here too confusing. In this scenario we instead expect current_permissions to be None, and we will display "no permissions have been defined for group Foo". #} {% set permissions_inherited = current_permissions and (current_permissions.folder.id != folder.id or current_permissions.group.id != group.id) %}The image server controls who can view, upload, and manage images by looking for permissions on folders in your image repository. Your folders are arranged in a hierarchy (a tree structure) and the permissions work in the same way. When you set the permission on a folder, it is inherited by all that folder's sub-folders (and their sub-folders, and so on). The permissions set on your image repository's root folder therefore act as the system-wide defaults.
Folder permissions are defined on a per-group basis. The special Public group represents anonymous users, those who are not logged into the image server itself. If you are using the image server alongside a public-facing web site, this is where the vast majority of image requests will come from. Image server users that are logged in may belong to several groups. In this case the user will be granted the most permissive access that the combination of all their groups provides. This might be hard to follow, so there is a tool that can calculate the overall folder permission for a single user .