I’m fairly new to NEOS but have 15+ years TYPO3 experience. I got the main parts going pretty fast in my first 2 projects with NEOS, although the learning curve is quite steep (eel, @context, flow queries, fusion, afx, @cache…). Now I am at the point where backend permissions are on the table and this is where I’m kind of stuck.
In the current project (NEOS 5), there is a site containing a part of relatively default content which is managed by privileged editors. Now, there are also editors who can be invited into the CMS by creating invitation emails with token based links (via backend module). When they accept the invitation, a default content page with some content elements is created as well as a backend account - so far, so good.
Of course, each user shall only see the default content mentioned earlier, as well as the pages which were created just for him. So first question: how can I create privilegeTargets (NodeTreePrivilege) dynamically?
Now, the invited users can link to the default content which is managed by the “admin” editors. Hence, they need to be able to see those contents, but must not be able to edit it. I added the ‘Neos\ContentRepository\Security\Authorization\Privilege\Node\EditNodePrivilege’, which leads to an ugly red exception box containing HTML code when such a used edits content on those restricted nodes. My expectation from a usability point of view is not to have editable properties in the first place instead of an exception afterwards. So second question: Is this the intended behavior or am I doing this wrong?
The last question is more generic: In TYPO3 there is very fine grained control over backend permissions based on entity properties, the page tree, assets and so on IN THE GUI. In NEOS, as far as I have understood it, there is just the policy.yaml which has to be set up by the developer containing hard coded persistence identifiers (or node paths). In my eyes this does in no way meet the expectations I have when using a CMS as those node criteria have to be placed in code, then deployed. So 3rd question: Is there a backend module available for this purpose or am I misinterpreting some concept here?
Yes there is a lot to learn in the beginning. I hope you are now at a point where you feel comfortable. We are always happy to get feedback on this, or even better, guides and helpers for other Neos beginners on docs.neos.io
The backend permissions are not fully where we would like them and we know about certain limitations in comparison to other systems. Complex permissions also have a huge impact on performance and maintainability of a site. I know that from quite a few TYPO3 projects I worked on or supported myself.
I helped building a similar system like you describe with Neos early last year. In that system users were imported and then could log into their own subpages and manage them. They could not see other pages except the parent pages of their own. But could also not edit them.
In this case we matched the username to a property of their pages in our policy. This worked well enough. So this would be dynamic as long as you only have one user per restricted node.
We don’t have enough policy handling in the Neos UI yet. But I improved the error messages in Neos 5.1 just recently to hopefully never show raw code anymore.
But you can prevent at least the inline editing in Fusion by also matching the current users role/name/etc. to the node. I think for making the inspector not editable one has to modify it via a plugin currently. This was not an issue at the time therefore I never looked into it further.
We don’t have a UI for policies currently. It’s not an easy task and most projects are able to solve their usual editorial permissions issues via the workspaces or adapt their concept. But you should look at this recent discussion about a new policy UI Permissions & Access Management UI. Maybe you can get in touch with the people discussing it.
Regarding the identifier, I never write them hard coded into my policies but use dynamic comparisons. But each of them has to be thought through as they can slow down database access a lot. So one of my projects has 2 user groups and each page and content can be assigned to them so they will only show up for members of those groups.
Besides that: I fully understand your thoughts as I was also coming from TYPO3 to Neos. And in TYPO3 you can just about do anything with permissions (also including all its drawbacks). But surprisingly many projects just need a handful of policies and then work fine. This might change at some point when there are more and more large websites built with Neos. But for us as a team other parts of Neos have been pushed and supported more by our customers and the community. Therefore the policies stayed mostly as they are. One of those many things we would love to make better.
My personal focus next year is the rewrite of the media module. There are also certain requirements for policies and customising it to individual projects.
Hope I could help you a bit with your questions. Feel free to also get in touch in Slack with the team and others.
