Introduction

In short terms DPAttachments inherits permissions from the item where the attachments belong to.

Permissions

This going to become really technical now but it will give you an understanding how DPAttachments calculates permissions for the attachments they belong to. The following step wise explanation describes how DPAttachments tries to guess the permissions.

1. The context where the attachment belongs to will be split by "dots". This means a context like com_dpcalendar.event will be split into DPCalendar and Event.
2. Then a table is tried to be instantiated with the name DPCalendarTableEvent (this is a default naming convention in Joomla).
3. If there is no table with that name the permissions are taken from the component with the name in the context. If no such permissions exist the last fallback are the permissions from the DPAttachments options.
4. If there could be loaded a table a check is done if a column with the name asset_id exists if no such column exists another check is done if there is a column with the name catid.
5. If one of these columns exist the permission check is done against their assets, if not a fallback will done against the permissions of the component or the permissions in the DPAttachments options.

Edit and Edit Own

If the user has no edit permissions but edit own on the item then an additional check will be done if the actual user is the author of the item. If this is the case the edit permission will be granted.

Edit State

If the actual logged in user is the author of the attachment he will always have edit state permissions to trash the item. This will not delete the item but it will be put into trashed state. The administrator can then delete the attachments in the backend permanently.

To fully understand what is going on have a look directly on the source of the canDo function on Github.

View Access

For every attachment the Joomla access level can be set as you are already familiar.