TYPO3 Core

...because by default the "admin" owns every page of the tree. If any editor also wants to edit what the admin created, he has to be member of a group that was manually associated with that very page of the tree.

It does not sound unlogical that a user needs to be part of a group to be able to edit something. Again be_acl makes a huge difference here.

Yes that does fix the issue. But as you can see... it's a "fix". So by default it is not good as it get's delivered with a standard TYPO3...

@Ben: For me as a semi-experienced TYPO3-integrator it was a good test to try to create a backenduser that actually can do something. And it was just horrible. It took hours to understand the concepts of groups, users and access-area, because there is no guidance. Some concepts are even just "not there" out-of-the-box (at least for an unexperienced user). That for itself is no problem, because TYPO3 isn't easy and oftentimes very complex, so this isn't something new... but, the backend seems to speak another language visually. So what did I do?

I wanted to create a user "editor". So I clicked on "User admin" and saw a list of one user called "admin". There was a little green plus icon "Add" and I clicked it, to add a user... In the following fields I set some things in the tabs, what the user is allowed to see, what he cannot do etc. ... I mounted a treepoint, saved it and switched to that user. The result was, I've created a user with certain permissions, a treemount, logged into it and: Nothing works. I don't even see the tree under the page-module. By then I was completely lost, because nothing in the backend gives you feedback what's going wrong after you obviously set the fields with descriptions that intended to do what I wanted to do.

I just accidentally found out to click on the "Access"-module (which is by no means connected to the area "User admin" where I've created my user and set his permissions) ... There I saw that the user "admin" owns every page and I thought... hmm. and now? If my user "editor" owns the page the admin cannot edit it in the future maybe... That seems not logical... And again I was completely lost... The concept of groups I didn't know and nothing gave a hint to that. If I just only want one user "editor", I obviously have to create a group (which seems to me to be for several users and not just one). But that's part of the concept that's really hard to understand at first when you have absolutely no hint.

Especially that you don't have to give the user any permissions or mounts, because the group sets this, is again completely confusing. For what purpose are all these fields when edit the user "editor"? Can't they be greyed out if I don't need them, because the group sets this already? I could go on for hours... It's just a general concept problem how this is presented in the backend. I don't criticise the technial concept of one user being in one group, that has access to certain areas etc. I just critice how it is, or better, is not presented in the backend...

I am eager to make a concept with Jens or anybody to improve this in general... Would that be ok for anybody?

I would love digg into that special topic.

I think I've already got a powerful Idea, with nice UX in mind to solve
that. But I wish to discuss that inside the team before I publish it here. :)

Greez Jens