PHPackages                             uandi/ui-permissions - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Authentication &amp; Authorization](/categories/authentication)
4. /
5. uandi/ui-permissions

ActiveTypo3-cms-extension[Authentication &amp; Authorization](/categories/authentication)

uandi/ui-permissions
====================

Deployable TYPO3 backend user permissions via YAML configuration files

1.0.0(5mo ago)0995—4.2%[1 issues](https://github.com/uandi/ui-permissions/issues)GPL-2.0-or-laterPHP

Since Nov 21Pushed 3mo agoCompare

[ Source](https://github.com/uandi/ui-permissions)[ Packagist](https://packagist.org/packages/uandi/ui-permissions)[ Docs](https://www.uandi.com)[ RSS](/packages/uandi-ui-permissions/feed)WikiDiscussions main Synced 1mo ago

READMEChangelog (1)Dependencies (14)Versions (3)Used By (0)

[![QA](https://github.com/uandi/ui-permissions/actions/workflows/qa.yml/badge.svg)](https://github.com/uandi/ui-permissions/actions/workflows/qa.yml/badge.svg)

Deployable TYPO3 Permissions
============================

[](#deployable-typo3-permissions)

TYPO3 extension to declaratively manage backend user group permissions as code.

If you have a TYPO3 project with any level of permissions for backend users you probably ran into one of the following problems:

- Creating the permissions in the TYPO3 backend takes a lot of time and clicks
- If you have different environments like INT, PPE and PROD, you would have to create the permissions on each environment
- You deployed something to PROD and forgot about the permissions until the customer calls because he can't see the new feature

This extension introduces deployable YAML descriptions of permissions that are gathered from all active extensions, merged, and written into the database via a CLI command. This makes permission changes reviewable (VCS), testable, and reproducible across environments.

What it does
------------

[](#what-it-does)

- Collects all files matching `*.permissions.yaml` from every active TYPO3 extension (recursive scan)
    - These YAML files basically contain abstractions of `be_groups` and `sys_filemounts` records.
- Merges all found configurations deterministically
- Writes/updates corresponding records in:
    - `sys_filemounts`
    - `be_groups`
- Resolves relations (e.g., `be_groups.subgroup`, `be_groups.file_mountpoints`) by referencing other items by their logical keys

Goals
-----

[](#goals)

- Treat backend permissions as configuration-as-code
- Enable safe deployments without manual backend tweaking
- Keep environments (INT/PPE/PROD) in sync
- Provide a clear, readable schema that is easy to review in pull requests
- If you know how TYPO3 permissions work and how they are stored in the DB, you'll have no trouble writing the YAML abstractions

Installation
------------

[](#installation)

```
composer require uandi/ui-permissions
```

### Extension configuration (Settings → Extension Configuration)

[](#extension-configuration-settings--extension-configuration)

- `pidBeGroups` (int): PID to store/update `be_groups` records
- `pidSysFilemounts` (int): PID to store/update `sys_filemounts` records
- `createFilemountDirectories` (bool): Create directories for filemounts if missing

These values are used by the repositories when inserting/updating records.

CLI usage
---------

[](#cli-usage)

Run via TYPO3 CLI. This command is ideally executed during deployments.

```
# Apply the current YAML permissions to the database
vendor/bin/typo3 ui_permissions:update
```

Where to place YAML files
-------------------------

[](#where-to-place-yaml-files)

While the collector scans the whole extension path, the recommended location is:

- `EXT:your_ext/Configuration/Permissions/YourName.permissions.yaml` for general purposes
- `EXT:your_ext/ContentBlocks/ContentElements/*/permissions/YourName.permissions.yaml` for ContentBlock elements.

Any filename ending with `.permissions.yaml` is picked up.

### Naming conventions (permission files and keys)

[](#naming-conventions-permission-files-and-keys)

Based on the “TYPO3 Backend User Management” concept (naming-for-purpose), use clear, prefixed keys. The map key of each item becomes its durable `permission_key` (and should also inform the filename):

- R\_&lt;Name&gt;: Role groups that aggregate capabilities via `subgroup`, e.g. `R_Editors`, `R_EditorsInChief`
- ACL\_&lt;Name&gt;: Access control scopes for single tables/features/CTypes, e.g. `ACL_tt_content_common`, `ACL_contentelement_gallery`
- FM\_&lt;Name&gt;: Filemount definitions and helper groups that attach filemounts, e.g. `FM_ProjeectIcons`
- DB\_&lt;Name&gt;: Database (page tree) mounts, e.g. `DB_Projeect`
- PG\_&lt;Name&gt;: Page-related presets, e.g. `PG_Projeect`
- L\_&lt;Name&gt;: Language-related presets for accessible languages, e.g. `L_Spanish`

#### Further reading

[](#further-reading)

-
-

#### Recommendations

[](#recommendations)

- Keep keys unique and stable; they act as IDs across environments
- Name files accordingly, e.g. `R_Editors.permissions.yaml` containing a `be_groups: R_Editors: ...` definition
- Compose roles (R\_*) from ACL\_* and FM\_\* using `subgroup` and `fileMountpoints`

YAML schema
-----------

[](#yaml-schema)

As was already noted, the YAML files are abstractions of the database records. So the top level keys describe which table we're dealing with:

- `sys_filemounts`: map of filemounts by a unique key ("permission key")
- `be_groups`: map of backend groups by a unique key ("permission key")

Each item’s map key becomes its `permission_key` in the database and is used to reference between items.

### sys\_filemounts item fields

[](#sys_filemounts-item-fields)

- `permission_key` (string, optional - map key will be used if missing)
- `title` (string, optional - map key will be used if missing)
- `description` (string, optional)
- `identifier` (string, e.g. `1:/assets`)
- `readOnly` (bool, default: false)

Legacy support: If `identifier` is missing, the pair `base` + `path` will be converted to `identifier` (`base:path`).

### be\_groups item fields (selection)

[](#be_groups-item-fields-selection)

- `permission_key` (string, optional - map key will be used if missing)
- `title` (string, optional - map key will be used if missing)
- `description` (string, optional)
- `tablesModify` (array|string CSV)
- `tablesSelect` (array|string CSV)
- `pagetypesSelect` (array|int|string CSV)
- `nonExcludeFields` (map `table: [field, ...]` or strings/CSV)
- `explicitAllowdeny` (map of tables → fields → \[values\])
    - Legacy support: `explicitAllowdeny: { allow: { table: { field: [values] } } }` also accepted
- `dbMountpoints` (array|int|string CSV of page IDs)
- `fileMountpoints` (array of filemount permission keys)
- `filePermissions` (array|string CSV)
- `subgroup` (array|string CSV of other be\_group permission keys)
- `groupMods` (array|string CSV)
- `TSconfig` (string)
- `allowedLanguages` (array|string CSV of sys\_language uids)
- `customOptions` (array|string CSV)
- `mfaProviders` (array)

Some fields are resolved after initial persistence (e.g., `subgroup`, `fileMountpoints`). See `Classes/Domain/Repository/BackendUserGroupRepository.php` for some insights.

### Merge behavior

[](#merge-behavior)

Merging is custom (see `ConfigurationCollector::mergeConfiguration()`):

- Associative arrays are merged recursively; later values override earlier scalars
- List arrays are concatenated and `array_unique()`-ed

This enables layering configurations across multiple extensions.

Examples
--------

[](#examples)

Examples of permissions files

### Example ACL for a content element (CType)

[](#example-acl-for-a-content-element-ctype)

```
be_groups:
  ACL_contentelement_gallery:
    tables_select: tt_content
    tables_modify: tt_content
    explicit_allowdeny:
      tt_content:
        CType:
          - contentelement_gallery
```

### Example role composed of many ACLs

[](#example-role-composed-of-many-acls)

```
be_groups:
  R_Editors:
    pagetypes_select: 1, 3, 4, 199, 254
    subgroup:
      - ACL_form_formframework
      - ACL_pages_common
      - ACL_sys_file_metadata
      - ACL_sys_file_reference
      - ACL_tt_content_common
      - ACL_tt_content_shortcut

      # Content Elements
      - ACL_contentelement_gallery
      - ACL_contentelement_media
      - ACL_contentelement_quote
      - ACL_contentelement_stage
      - ACL_contentelement_teaser
      - ACL_contentelement_textmedia

      # Grids
      - ACL_contentelement_grid2columns50-50
      - ACL_contentelement_grid3columns33-33-33
      - ACL_contentelement_grid4columns25-25-25-25
    groupMods:
      - web_layout
      - media_management
      - user_setup
```

### Example filemounts (FM\_\*) and their respective be\_groups

[](#example-filemounts-fm_-and-their-respective-be_groups)

```
sys_filemounts:
  FM_ProjeectIcons:
    title: 'Assets'
    description: 'Base Fileadmin Folder for Icons'
    identifier: '1:/user_upload/Projeect/Icons/'

  FM_ProjeectIcons_ReadOnly:
    title: 'Icons'
    description: 'Base Fileadmin Folder for Icons (Read Only)'
    identifier: '1:/user_upload/Projeect/Icons/'
    read_only: 1

be_groups:
  FM_ProjeectIcons:
    file_mountpoints:
      - FM_ProjeectIcons

  FM_ProjeectIcons_ReadOnly:
    file_mountpoints:
      - FM_ProjeectIcons_ReadOnly
```

### Example database mount (DB\_\*)

[](#example-database-mount-db_)

```
be_groups:
  DB_Projeect:
    db_mountpoints: 1
```

Tips
----

[](#tips)

- Keep permission keys unique and stable; they become the durable identifier (`permission_key`) across environments
- Split large setups into multiple files; merging will combine them
- Prefer arrays over CSV for readability, but both are supported in many fields

What's next
-----------

[](#whats-next)

- CLI Command to create YAML files from existing permissions in the database to make it easier to introduce this extension to existing projects
- Maybe try to introduce some level of plausibility/error checks to make it easier to find misconfigurations in the YAML abstraction files

###  Health Score

36

—

LowBetter than 82% of packages

Maintenance76

Regular maintenance activity

Popularity19

Limited adoption so far

Community6

Small or concentrated contributor base

Maturity36

Early-stage or recently created project

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Unknown

Total

1

Last Release

178d ago

### Community

Maintainers

![](https://www.gravatar.com/avatar/c468799e607014a48d4360f8a51d9bba9e8bced1319884834a1ad8e9b985f0f6?d=identicon)[Flimmerkiste](/maintainers/Flimmerkiste)

---

Top Contributors

[![Flimmerkiste](https://avatars.githubusercontent.com/u/3634617?v=4)](https://github.com/Flimmerkiste "Flimmerkiste (3 commits)")

---

Tags

permissions

###  Code Quality

Static AnalysisPHPStan

Code StylePHP CS Fixer

Type Coverage Yes

### Embed Badge

![Health badge](/badges/uandi-ui-permissions/health.svg)

```
[![Health](https://phpackages.com/badges/uandi-ui-permissions/health.svg)](https://phpackages.com/packages/uandi-ui-permissions)
```

###  Alternatives

[spatie/laravel-permission

Permission handling for Laravel 12 and up

12.9k89.8M1.0k](/packages/spatie-laravel-permission)[santigarcor/laratrust

This package provides a flexible way to add Role-based Permissions to Laravel

2.3k5.4M43](/packages/santigarcor-laratrust)[bezhansalleh/filament-shield

Filament support for `spatie/laravel-permission`.

2.8k2.9M88](/packages/bezhansalleh-filament-shield)[jeremykenedy/laravel-roles

A Powerful package for handling roles and permissions in Laravel. Supports Laravel 5.3 up to 12.

1.0k826.8k7](/packages/jeremykenedy-laravel-roles)[beatswitch/lock

A flexible, driver based Acl package for PHP 5.4+

870304.7k2](/packages/beatswitch-lock)[pktharindu/nova-permissions

Laravel Nova Grouped Permissions (ACL)

136387.1k](/packages/pktharindu-nova-permissions)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)
