JoomGallery uses the Joomla! Access Control List (ACL) system to determine what users and user groups may see and do. The familiar Joomla! concepts of user groups, inherited permissions, allowed actions, and denied actions therefore also apply to JoomGallery.
If you are new to Joomla permissions, begin with the official Joomla! Access Control documentation. This article assumes that you already understand and are familiar with Joomla! ACL and its related permissions and view levels. We will explain here the additional or modified functionalities added and provided by JoomGallery.
Permissions and access levels are different
Joomla! uses two related but different mechanisms:
- Access levels determine who can view an item.
- Permissions determine which actions a user can perform, such as creating, editing, deleting, uploading, or changing the state of an item.
Making a gallery visible to a user does not automatically give that user permission to edit it. Likewise, granting edit permission does not necessarily make every gallery visible in the frontend.
Permission hierarchy
JoomGallery permissions are evaluated through a hierarchy. Permissions configured at a more specific level can supplement or override inherited permissions from a higher level.
- Joomla! global permissions
- JoomGallery component permissions
- JoomGallery category permissions (category tree hierarchy)
- Menu item settings
A category inherits permissions from its parent category. If no permission is set on the category, JoomGallery continues upwards through the category tree and finally to the component and Joomla! global permissions.
Permission states
- Inherited
- No decision is made at the current level. The result is inherited from a parent user group or a higher level in the permission hierarchy.
- Allowed
- The selected user group is permitted to perform the action unless an applicable rule produces an effective denial.
- Denied
- The selected user group is not permitted to perform the action. As in Joomla! core ACL, an effective denial takes precedence over a general allowance within the evaluated rule hierarchy.
Important: A user can belong to more than one user group. Always consider the permissions inherited from every group to which the user belongs.
Image permissions are controlled by categories
JoomGallery does not store individual ACL settings for every image. The permissions of an image are determined through the category containing the image.
To change the permissions for a group of images:
- Open the relevant JoomGallery category.
- Open its Permissions tab.
- Select the required user group.
- Configure the image permissions for that category.
- Save the category.
The configured image permissions apply to the images in that category and can be inherited through the category hierarchy. Image-specific permission settings are not available.
Moving an image to another category can change its effective permissions because the image will then use the permission hierarchy of its new category.
General permissions
JoomGallery supports Joomla!'s standard permission concepts, including the following common actions:
| Permission Title | Permission Rule | Purpose |
|---|---|---|
| Configure ACL & Options | core.admin | Allows management of JoomGallery options and permissions. |
| Access Administration Interface | core.manage | Allows access to JoomGallery in the Joomla! administrator area. |
| Create | core.create | Allows creation of supported JoomGallery items. |
| Upload | joom.upload | Allows images to be uploaded to permitted categories. |
| Edit | core.edit | Allows existing items to be modified, regardless of ownership. |
| Edit State | core.edit.state | Allows state changes such as publishing, unpublishing, approving, or unapproving. |
| Delete | core.delete | Allows items to be deleted, regardless of ownership. |
| Connect | joom.connect | Allows supported items to be connected to collections or other JoomGallery structures. |
Permissions for owned items
JoomGallery extends Joomla! ACL with additional own and in-own permissions. These permissions make it possible to give users additional rights over content that they own without granting the same rights over all JoomGallery content.
Own permissions
An own permission applies when the current user is the owner of the item being accessed.
Examples include:
- Edit Own — edit an owned item.
- Delete Own — delete an owned item.
For example, a user group may have Edit set to Denied or Inherited while Edit Own is Allowed. Members of that group can then edit their own applicable items without being able to edit items belonging to other users.
In-own permissions
An in-own permission applies to actions performed inside an item owned by the current user. This is especially useful for categories.
Examples include:
- Create in Own — create a subcategory or supported item inside an owned category.
- Upload in Own — upload images into an owned category.
- Connect in Own — connect supported items within an owned collection.
This allows a user to manage content within their own category or collection without receiving the equivalent permission for all JoomGallery categories or collections.
Own permissions take precedence
When an ownership rule applies, its explicit result takes precedence over the corresponding general permission.
| General permission | Applicable own permission | Effective result for the owner |
|---|---|---|
| Denied or not allowed | Allowed | Allowed |
| Allowed | Denied | Denied |
| Allowed | Inherited | Allowed through the general permission |
| Denied or not allowed | Inherited | Not allowed |
For users who do not own the affected item or parent item, the own or in-own permission does not apply. Their access is determined by the general permission.
Editing from the frontend
JoomGallery's frontend user views usually display only items owned by the logged-in user. This is a display filter and should not be confused with an ACL restriction.
A user who has the general Edit permission may edit images, categories, or collections belonging to other users through the frontend, even if those items are not shown in an owner-filtered list. This is intentional: the general Edit permission authorizes editing regardless of ownership.
Grant the general Edit permission only to groups that should be able to modify other users' items. To restrict a group to its own content, grant the appropriate Edit Own permission instead of the general Edit permission.
Changing ownership
Ownership is recorded in the Owner or Created By field.
The following users may change the ownership of an existing image, category, or collection:
- The current owner of the item.
-
A user with JoomGallery Access Administration Interface
(
core.manage) permission. -
A user with JoomGallery Configure ACL & Options
(
core.admin) permission. - A Joomla! Super User.
The owner of an image, category, or collection may hand the item over to another user. After the transfer, the previous owner may lose permissions that were provided only through an own permission.
For other JoomGallery item types, changing ownership requires
core.manage, core.admin, or Super User
privileges.
A user with the general Edit permission can modify another user's item, but this permission alone does not allow that user to take ownership of it.
Understanding calculated permission results
Joomla! permission forms show a calculated result for the selected user group. This result is useful for normal permissions, but it may be misleading for JoomGallery's own and in-own permissions.
The permission form does not know which specific user and item will be checked later. It therefore cannot always determine whether that user is the owner of the item or its parent category or collection.
Known display limitation: The calculated result shown in the Permissions tab may be incorrect or incomplete for own and in-own permissions. Ownership is evaluated when the user performs the action, not when the permission form is displayed.
When troubleshooting an own permission, test with:
- A real user who belongs to the affected user group.
- An item owned by that user.
- An equivalent item owned by another user.
- The exact frontend or administrator action being tested.
Configuration examples
Allow users to edit only their own images
- Do not grant the user group the general Edit permission.
- Grant Edit Own for images.
- Ensure that the affected images have the users recorded as their owners.
Allow category owners to upload images
- Do not grant unrestricted Upload permission if it is not required.
- Grant Upload in Own to the user group.
- Assign each managed category to the appropriate owner.
Allow editors to modify all gallery content
- Grant the user group the general Edit permission.
- Grant Edit State separately if users should also publish, unpublish, approve, or unapprove items.
- Grant Delete separately if users should be able to delete items.
The Edit permission does not automatically include Edit State or Delete.
Recommended administration practices
- Grant general permissions only when users need access to all applicable items.
- Prefer own and in-own permissions for user-managed galleries.
- Configure permissions on parent categories where possible to simplify inheritance.
- Use explicit Denied settings carefully because they can affect inherited permissions.
- Test permission changes using a non-Super-User account.
- Test both owned and non-owned items.
- Verify Edit State, Delete, Upload, and Edit separately.
- Record which groups are permitted to transfer ownership of gallery content.
Summary
- JoomGallery ACL is based on Joomla!'s core ACL system.
- Image permissions are inherited through the image's category.
- Permissions follow the global, component, category, and menu hierarchy.
- Own permissions apply to items owned by the current user.
- In-own permissions apply to actions inside owned categories or collections.
- Applicable own permissions take precedence over general permissions.
- General Edit permission allows editing other users' applicable items.
- Frontend owner lists do not replace ACL checks.
- Owners may transfer their images, categories, and collections.
- Calculated permission results may not accurately represent ownership-based permissions.