Feature #31874


A new user without being in a group cannot do anything

Added by Lars Zimmermann over 12 years ago. Updated about 7 years ago.

Should have
Backend User Interface
Target version:
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Sprint Focus:
Actions #1

Updated by Lars Zimmermann over 12 years ago

...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.

Actions #2

Updated by Ben van 't Ende over 12 years ago

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.

Actions #3

Updated by Jens Hoffmann over 12 years ago

  • Category set to Technical
  • Status changed from New to Needs Feedback
  • Assignee set to Lars Zimmermann

There is TS to "fix" or better change the Default behavior here.

# Rights for newly created pages
    permissions {
        groupid = 1
        user = show, editcontent, edit, new, delete
        group = show, editcontent, edit, new, delete
        everybody = show, editcontent, edit, new

Douse that fix your issue?

Actions #4

Updated by Lars Zimmermann over 12 years ago

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?

Actions #5

Updated by Jens Hoffmann over 12 years ago

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

Actions #6

Updated by Benni Mack over 7 years ago

  • Project changed from 78 to TYPO3 Core
  • Category changed from Technical to Backend User Interface
  • TYPO3 Version set to 8
  • Is Regression set to No
Actions #7

Updated by Alexander Opitz over 7 years ago

  • Tracker changed from Bug to Feature
  • Status changed from Needs Feedback to New
  • Target version set to 9 LTS

Its more a feature request

Actions #8

Updated by Christian Kuhn about 7 years ago

  • Status changed from New to Closed

the access rights setup clearly needs a better interface. however, i think that should be done in fresh tickets if anyone really starts with active thoughts on that.


Also available in: Atom PDF