Project

General

Profile

Actions
Copy link

Feature #31872

closed

Group hierarchy

Added by Lars Zimmermann about 13 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Backend User Interface
Target version:
-
Start date:
2011-11-16
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

You have to create a group "All Users". Under the "Access"-module you then have to set this group for all pages.
Other groups like "editors" or "advanced editors" need this group "All users" as a subgroup, which is a wrong relation, because "All users" are the on-top-group or parent-group that "owns" the tree...

The relationship seems to be connected in the wrong direction. At least for backendusers who have to set up the groups...

Files

Screen_Shot_2011-11-16_at_18.34.55.png (61 KB) Screen_Shot_2011-11-16_at_18.34.55.png Steffen Gebert, 2011-11-16 18:36

Related issues 1 (0 open — 1 closed)

Related to TYPO3 Core - Bug #31873: Problematic by default: No permission for editors/everybodyClosed2011-11-16

Actions
Actions
Copy link
 #2

Updated by Jens Hoffmann about 13 years ago

  • Status changed from New to Needs Feedback

Steffen could you add some explanation to your screenshot?

Actions
Copy link
 #3

Updated by Steffen Gebert about 13 years ago

Said in short (and Lars agreed on that): The label Sub Groups should be sth. like Parent Groups.

From my technical perspective, it is this way

            +-----------+
            | All users |
            +-----------+
                  |
                  |
  +-----------+   |    +---------+
  |  Editors  |---+----|  Sales  |
  +-----------+        +---------+

All users is the parent category of its two subgroups. The label in TYPO3 is exactly the other way around. Furthermore, you can only specify the relationship between the two groups in Editors, not in All users

Actions
Copy link
 #4

Updated by Lars Zimmermann about 13 years ago

Yes. I totally agree, that is what I wanted to say. The group "all users" is set under the access-module, but is a subgroup of editor and other users. That is exactly the other way round...

Actions
Copy link
 #5

Updated by Jens Hoffmann about 13 years ago

To me we need bring this in the context perspective.

If I don't miss the major point here, I would say that:
Lars would be well served if he would start upon the
Introduction Package, where it's build / setup as he
expects the system to behave. But we need to keep
in mind, that there are manny Agencys who build up
there projects form scratch, from them ist's perfect
like it is right now. I would love to discuss that deep-
er with you guys. Could we meet via Skype and find
a solution in between those tow cases.

Actions
Copy link
 #6

Updated by Steffen Gebert about 13 years ago

Jens, I'm also against an "All Users" group by default.

I try to discuss the sub/parent group thing during the weekend with the others (or/and you), whther it wouldn't be better to really change the label as suggested.

Actions
Copy link
 #7

Updated by Felix Kopp over 12 years ago

A quick fix would be an additional description next to the field explaining excatly how subgroups are related to the current group edited. Either as label or help icon.

Actions
Copy link
 #8

Updated by Benni Mack about 8 years ago

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

Updated by Alexander Opitz almost 8 years ago

  • Tracker changed from Bug to Feature
  • Status changed from Needs Feedback to New
  • Target version set to 9 LTS
Actions
Copy link
 #10

Updated by Mona Muzaffar about 7 years ago

  • Related to Bug #31873: Problematic by default: No permission for editors/everybody added
Actions
Copy link
 #11

Updated by Riccardo De Contardi about 7 years ago

  • Status changed from New to Needs Feedback

The label and help text has changed since at least version 7:

Instead of "Subgroups" the label is "*Inherit settings from groups:*" and the help text is:

Backend usergroup: Inherit settings from groups
All settings from the selected groups will be merged with the properties from this group, for example DB mounts, permissions, TSconfig, etc.

Details

The properties of subgroups are added to the properties of this group and basically they will simply be added to the list of member groups of any user which is a member of this group.
This feature provides a great way to create 'Supervisor' user groups.

could it be sufficient to consider this issue closed?

Actions
Copy link
 #12

Updated by Steffen Gebert almost 7 years ago

okay, makes more sense now. Thanks!

Actions
Copy link
 #13

Updated by Riccardo De Contardi almost 7 years ago

  • Status changed from Needs Feedback to Closed
  • Target version deleted (9 LTS)

I close this issue for now; the label and description on versions 7.6.x and higher convey a better understanding of groups hierarchy.

If you think that this is the wrong decision, please reopen it or open a new issue with a reference to this one. Thank you.

Actions
Copy link

Also available in: Atom PDF