TYPO3’s backend permission system is powerful but notoriously opaque. Access rights for backend groups (allowed fields, tables, content element types, page types, languages) are configured in huge abstract multi-select lists inside the be_groups record — completely disconnected from where those permissions actually take effect. Admins and integrators cannot easily answer the simple question: “What can this group actually see and edit on this form?” The result is trial-and-error configuration, over-permissioning (a real security problem), and permissions that nobody dares to touch once they “work”.
Visual Permissions solves this in-context: an admin picks a backend group from a toolbar item and activates a visual mode. Every record form then shows per-field overlays — allowed, denied, or inherited through the subgroup chain. Clicking a field queues a grant/revoke change; all queued changes are reviewed and applied as one batch, protected by TYPO3’s sudo mode. Table-level access (including subgroup inheritance, mirroring TYPO3’s login-time merge) is visualized the same way.
What must be achieve by 30th of November 2026?
Stable 1.0 release, publicly available on GitHub, Packagist, and TER
Complete the permission domains: in addition to the existing field and table permissions, add visual inspection and editing of content element types (explicit_allowdeny), page types, and allowed languages.
Visualize the inheritance chain: show which subgroup a permission is inherited from, not just that it is inherited.
Compatibility with TYPO3 14 and 13
Extended automated test coverage (PHPUnit unit + functional, Playwright E2E) maintained in public CI as a quality baseline and as a reference for testing modern backend extensions.
What is the potential impact of your idea for the overall goal?
Security: over-permissioning happens because correct configuration is hard to verify. Making permissions visible and verifiable in context leads to least-privilege setups and more trustworthy TYPO3 installations.
Lower entry barrier: the permission system is one of the steepest learning curves for new integrators and admins. Visual Permissions turns it from a feared expert topic into something discoverable — making TYPO3 more welcoming and beginner-friendly.
Efficiency for agencies: permission tickets (““editor X suddenly can’t edit field Y””) are a constant support cost. In-context inspection reduces diagnosis from guesswork to seconds.
It turns one of TYPO3’s genuine differentiators — its uniquely granular permission system — from a pain point into a selling point.
How does your Idea align with the TYPO3 Association Strategy
The idea directly supports the strategic goal “Strengthening the Innovation Process and Product Ownership”, specifically its aim to make TYPO3 “more welcoming and beginner-friendly”: it removes one of the best-known usability barriers in the backend without requiring core changes. By making fine-grained access control verifiable, it also strengthens the trust and security story that underpins “Enabling Informed Decisions” — TYPO3’s positioning around digital sovereignty and enterprise-grade open source. The project is a focused product contribution, not a side quest: it improves the daily experience of the existing core feature set.
these are two different layers of the problem. The preset ideas are about how permissions are stored and deployed. My idea is about seeing and editing them where they take effect — “what can this group actually do on this form, and why?” That question stays open no matter how the permissions get deployed.
So there’s no overlap with the earlier ideas, and I’d like to keep the scope focused on exactly this one problem rather than combining it with deployment concerns. I’m not going to build some kind of “jack-of-all-trades” product here.
Here’s a mockup how that could look like. Red = no permissions granted, Green = permissions granted, Admin fields are locked.
And something similar for every other aspect of the permission system (through UI overlays):
The idea is good, but I’d say the description of the idea is too broad. It should be specified that the goal is to toggle visibility of fields, and consider change of restrictions, based on the TCA option “exclude” of each field. I know this is quite technical, but that limits the exact perimeter of what may be achieved imho with the discussed budget.
For instance I can think of dynamic fields created via custom business logic during the preparation of the TCA (aka “dynamic TCA”) and this wouldn’t be tackled with, or at least for sure not within the suggested budget.
I like the idea! But specification should just be a bit more technical on that aspect.
Thanks, the point about the description is fair. Let me be more concrete.
For fields the scope is exactly the TCA exclude flag and the matching be_groups.non_exclude_fields column, nothing more. Every field in a form gets one state: allowed, denied, inherited from a subgroup, cannot be restricted at all (no exclude flag), admin only (HIDE_FOR_NON_ADMINS) or read only. A click on a field which can be restricted puts a grant or a revoke into a queue, and the queue is written back to non_exclude_fields.
The other parts of the idea work the same way, each one on an existing be_groups column: table access on tables_modify, content element types and page types on explicit_allowdeny, languages on allowed_languages and so on. So there is no new permission concept, no own storage format and no core change–only (which sounds a bit simpler as it is) a visual layer on top of what is already there. That is what keeps the budget realistic.
About dynamic TCA: I think this is not a problem, because the plan is to work with the generated TCA and nothing else. The check happens on $GLOBALS[‘TCA’] of the current request, and the overlay is attached where FormEngine renders a field. It does not matter if a field comes from the core, from Configuration/TCA/Overrides or from custom logic during TCA preparation — if it is in the generated TCA and has the exclude flag, it is handled like every other field. So dynamic fields need no extra work and no extra budget.
The case which is really record dependent is FlexForm. The data structure depends on the record (CType, plugin). I would put that as an optional goal, not as a promise. If it does not fit into the budget, FlexForm fields simply get no overlay for now.
I hope this shows better where the limits are. Please take this answer as the more technical part of the description. Thanks again for the feedback!
