The trigger for this was this change record for D10.1.x where two new permissions were introduced: "Delete any file" and "Delete own files".
We currently have individual per-file-type permission for the following: - [FILETYPE]: Edit own files - [FILETYPE]: Edit any files - [FILETYPE]: Delete own files - [FILETYPE]: Delete any files - [FILETYPE]: Download own files - [FILETYPE]: Download any files
In addition we have the following "global" file-related permissions (besides the "Bypass file access control" permissions, which allows every operation against any file type): - View own private files - View private files - View own files - View files - Manage or replace any file - Delete any file
This issue here is mainly about adding the following two permissions, for completeness/consistency: - Manage or replace own files - Delete own files
These new permissions would apply to all current and future file types, same as their "any" counterparts.
In addition to the above two permissions, I was wondering about the following:
1. The "View files" permission has the following description: Includes the following stream wrappers: Public files.. Should we add the same description in the "View own files" permission? (currently has no description)
2. Should we rename the human-readable names of the "View own files" and "View files" permissions to "View own non-private files" and "View non-private files"? I am intentionally proposing to use non-private instead of public, as there may be other stream wrappers that are not private, and non-private seems like a good "umbrella" term for all of them.
3. Should we rename "[FILETYPE]: Edit own files" and "[FILETYPE]: Edit any files" to use Manage or replace instead of Edit?
4. (This is the opposite/alternative of the previous point) Should we rename "Manage or replace any file" and "Manage or replace own files" to use Edit instead of Manage or replace? (in which case we can add some description to clarify that "edit" means "manage and replace")
Recent comments
If there is time, carried over from last week as we didn't have time to look at it then, I would welcome feedback on the approach I've taken to: [A11Y] Update aria role on...
July 16th, 2026 - Weekly Meetings
If there's some time left after discussing code signing (yay!)... 1. Friendly reminder: usage stats are still broken Didn't data get fetched at all (broken parser) or is it a display...
July 16th, 2026 - Weekly Meetings
Sorry - it is the field_group module. However, last night I switched off proxying to the site and proved to Cloudflare Support that it was NOT a Backdrop issue. After a thorough...
Cloudflare specific advice needed [SOLVED]