en	This is the Backend administration user groups available for the Backend users. These determine the access credentials for the Backend users.

en	Groups contain the main permission settings you can set for a backend user. Many users can be members of the same group and thus share permissions. When a user is a member of many groups (including sub-groups) then the permission settings are added together so that the more groups a user is a member of, the more access is granted to him.

en	be_users, "Inside TYPO3" about users / groups | https://docs.typo3.org/typo3cms/InsideTypo3Reference/CoreArchitecture/AccessControl/UsersAndGroups/, How to set up a backend user | https://docs.typo3.org/typo3cms/InsideTypo3Reference/CoreArchitecture/AccessControl/SettingUpANewUser/, Setting up groups (from "Getting Started") | https://docs.typo3.org/typo3cms/GettingStartedTutorial/EditAndCreatePagesAndContent/CreateUsersGroups/

en	EXT:lang/cshimages/be_groups_2.png, EXT:lang/cshimages/be_groups_1.png

en	Backend Usergroups are found in the root of the page tree where only "admin" users can edit them. The usergroups with red icons in this image are the ones with Access Lists enabled. The blue are just plain usergroups. This usergroup has Access Lists enabled. In the Access Lists you specify which modules, tables, database fields etc. the group members can access in TYPO3.

en	Name of the Backend usergroup. The name should be descriptive and can always be changed later.

en	Backend Usergroups are identified by their "uid" field value (integer) and therefore the title can always be changed. The "uid" can never be changed for a user group.

en	EXT:lang/cshimages/be_groups_2.png

en	The usergroup title is shown in the record lists.

en	Define page tree root points for the group members.

en	The page tree in TYPO3 must have some points-of-entry defined. Here you should insert one or more references to a page which will represent a new root page for the page tree. This is called a "Database mount" or "DB mount". DB mounts <i>may</i> be inherited by the users which are members of this group. This depends on whether the user is configured to include the mounts set in the member groups. However it's recommended to use backend user groups like this to configure mounts. Especially if they need to be shared among many users.

en	be_groups:file_mountpoints, be_users:db_mountpoints, be_users:options, xMOD_csh_corebe:list_module

en	EXT:lang/cshimages/be_groups_3.png, EXT:lang/cshimages/be_groups_4.png

en	Here a page is added as a "DB mount"... ... and in the page tree of member users this will become the starting point for the page tree.

en	Define startpoints for the file folder tree.

en	The file folder tree is used by all File-submodules to navigate the file folders on the webserver. If you want users to access the servers file system through TYPO3 they need at least one File Mount (and access to eg. File > Filelist module). You can mount a path in "fileadmin/" relative to the TYPO3 installation or you can mount an absolute path somewhere else on the server (outside webroot!). The last requires that $TYPO3_CONF_VARS[BE][lockRootPath] is defined. The path you mount is defined by the Filemount record you refer to by this field. So a File Mount just points to another record inside of which the details are configured. See screenshots below. "admin" users always have the "fileadmin/" folder mounted by default. Notice; as with 'DB mounts' the file folder mounts may be inherited by the users which are members of this group.

en	be_groups:db_mountpoints, be_users:file_mountpoints, be_users:options, be_users, sys_filemounts, xMOD_csh_corebe:filelist_module, More about File Mounts | https://docs.typo3.org/typo3cms/InsideTypo3Reference/CoreArchitecture/AccessControl/MoreAboutFileMounts/

en	EXT:lang/cshimages/be_groups_5.png, EXT:lang/cshimages/be_groups_6.png, EXT:lang/cshimages/be_groups_7.png, EXT:lang/cshimages/be_groups_8.png

en	The File Mounts are references to records from the "Filemounts" table. In the Filemount record you define whether the path should be absolute (must be within $TYPO3_CONF_VARS[BE][lockRootPath]) or relative to "fileadmin/". In this case the Filemount points to "fileadmin/user_upload/" This is the page tree of the "admin" user. Notice the folder "user_upload" which is the folder referred to by the File Mount record. This shows the mounted folder as seen by a user who was member of the group. Filemount records are also created in the page tree root.

en	Select file operation permissions for the group members.

en	These settings relate to the functions found in the File>Filelist module as well as general upload of files. <strong>Notice</strong> that these settings apply to all members of this group and extend the users permissions accordingly.

en	be_groups:file_mountpoints, be_users:file_mountpoints, be_users:file_permissions

en	Select file operation permissions for the group members.

en	These settings relate to the functions found in the File>Filelist module as well as general upload of files. <strong>Notice</strong> that these settings apply to all members of this group and extend the users permissions accordingly.

en	be_groups:file_mountpoints, be_users:file_mountpoints, be_users:file_permissions

en	Select which 'Types' of Pages the members may set.

en	This option limits the number of valid choices for the user when he is about to select a page type. Choice of Page types (doktype) for a page is associated with a) a special icon for the page, b) permitted tables on the page (see $PAGES_TYPES global variable) and c) if the page is a web page or "system folder" type.

en	pages:doktype, be_groups:inc_access_lists

en	EXT:lang/cshimages/be_groups_9.png

en	The list of typical page types available in a CMS context. Selecting Page types for a usergroup defines which of these options can be selected by member users.

en	Select which tables the members may modify.

en	An important part of setting permissions is to define which database tables a user is allowed to modify. Tables allowed for modification is automatically also allowed for selection and thus you don't need to set tables entered here in the "Tables (listing)" box. <strong>Notice</strong> that this list adds to the fields selected in other member groups of a user.

en	be_groups:tables_select, be_groups:inc_access_lists, xMOD_csh_corebe:new_ce

en	EXT:lang/cshimages/be_groups_10.png, EXT:lang/cshimages/be_groups_15.png, EXT:lang/cshimages/be_groups_11.png

en	The screenshot above shows how the "Create new record" dialog looks for a user limited to editing only "Page" and "Page content" elements. The two tables are simply added to the list of "Tables (modify)" in the group Access Lists. This is (an example of) the full amount of elements that can be created on the page by the "admin" user for whom there are no restrictions.

en	Select which tables the members may see in record lists ('modify' tables does not need to be re-entered here!).

en	This determines which tables - in addition to those selected in the "Tables (modify)" box - may be viewed and listed for the member users. He is not able to <em>edit</em> the table - only select the records and view the content. This list is not very important. It's a pretty rare situation that a user may select tables but not modify them.

en	be_groups:tables_modify, be_groups:inc_access_lists

en	Certain table fields are not available by default. Those fields can be explicitly enabled for the group members here.

en	"Allowed excludefields" allows you to detail the permissions granted to tables. By default all these fields are not available to users but must be specifically enabled by being selected here. One application of this is that pages are usually hidden by default and that the hidden field is not available for a user unless he has been granted access by this list of "Allowed excludefields". So the user may create a new page, but cannot un-hide the page - unless of course he has been assigned the "Page: Hide page" exclude field through one of his member groups. Of course it does not make any sense to add fields from tables which are not included in the list of tables allowed to be modified.

en	be_groups:inc_access_lists, Examples from "Getting Started" | https://docs.typo3.org/typo3cms/GettingStartedTutorial/EditAndCreatePagesAndContent/CreateUsersGroups/

en	EXT:lang/cshimages/be_groups_14.png

en	Disables a user group.

en	If you disable a user group all users which are members of the group will in effect not inherit any properties this group may have given them.

en	Enter the host name from which the user is forced to login.

en	A TYPO3 system may host multiple websites on multiple domains. Therefore this option secures that users can login only from a certain host name. Setting this to for example "www.my-domain.com" will require a user to be logged in from that domain if membership of this group should be gained. Otherwise the group will be ignored for the user.

en	be_users:lockToDomain, fe_users:lockToDomain, fe_groups:lockToDomain

en	Select available backend modules for the group members.

en	This determines which 'menu items' are available for the group members. This list of modules is added to any modules selected in other member groups of a user as well as the corresponding field of the user himself.

en	be_users:userMods, be_groups:inc_access_lists, Backend Interface | https://docs.typo3.org/typo3cms/InsideTypo3Reference/CoreArchitecture/Backend/

en	EXT:lang/cshimages/be_groups_12.png, EXT:lang/cshimages/be_groups_13.png

en	The Backend Modules available for a user is reflected in the menu items of the backend. For most regular users only modules in the Web and File main modules are enabled. Typically "Web > Page" is used for editing of page content. This is the assignment of Backend Modules to the user from the screenshot above. All four Web sub-modules and the two User sub-modules are configured here. However the File > Filelist module must have been configured for another member group of this user (or inside the user profile itself which is also possible). The Help modules are all accessible by default and does not require explicit access.

en	Select whether the Access Lists for Page type, Tables, Module and Allowed excludefield are enabled for this group.

en	If this option is disabled the Access Lists cannot be configured for the group. When Access Lists are disabled the icon for the group is blue while it is red when Access Lists are enabled.

en	be_groups:pagetypes_select, be_groups:tables_modify, be_groups:tables_select, be_groups:groupMods, be_groups:non_exclude_fields

en	Enter a short description of the user group, what it is for and who should be members. This is for internal use only.

en	fe_groups:description

en	User TSconfig: Additional configuration through TypoScript style values (Advanced).

en	User TSconfig can be set for each backend user and group. Configuration set for backend groups is inherited by the user who is a member of those groups. The available options typically cover user settings like those found in the User>Setup module (in fact options from that module can be forcibly overridden from User TSconfig!), configuration of the "Admin Panel" (frontend), various backend tweaks (lock user to IP, may user clear all cache?, width of the navigation frame etc.) and backend module configuration (overriding any configuration set for backend modules in Page TSconfig).

en	TypoScript syntax without conditions and constants.

en	be_users:TSconfig fe_users:TSconfig fe_groups:TSconfig pages:TSconfig, TSconfig Reference| https://docs.typo3.org/typo3cms/TSconfigReference/UserTsconfig/, TypoScript Syntax | https://docs.typo3.org/typo3cms/TyposcriptSyntaxReference/

en	EXT:lang/cshimages/be_groups_16.png, EXT:lang/cshimages/be_groups_17.png

en	In the TSconfig field help is right at hand - just click the TS wizard icon, then a window will pop up. In the pop-up window you will see a tree of possible configuration values. These are extracted from the TSconfig manual. You can click around to find the options you need to set through this wizard.

en	This option will prevent the user group from showing up in lists, where user groups are selected.

en	This will affect the list of user groups in the Task Center To-Do and Messages parts as well as the Web>Access module. The option is extremely useful if you have general user groups defining some global properties which all your users are members of. Then you would probably not like all those users to 'see' each other through the membership of this group, for instance sending messages or To-Dos to each other. And this is what is option will prevent.

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

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

en	Select field values to explicitly deny or allow for user group members.

en	Selector box fields can be configured for access control on value level. This list represents all values that are configured for access control. Each value can be configured to require either explicit access (Allow) or explicit denial (Deny). If a value has the prefix "Allow" (green icon) it means that by default users <em>cannot</em> set this value unless they are member of a user group which explicitly allows it (by setting this checkbox). If a value has the prefix "Deny" (red icon) it means that by default users can set this value unless they are member of a user group which explicitly denies it (by setting this checkbox). The list is organized so values from the same selector box is listed together. If values from a selectorbox is not present in the allow/deny list it simply means they are not evaluated and hence they can be set by anyone having access to the field in general.

en	EXT:lang/cshimages/be_groups_19.png

en	Select which record languages the group members are limited to edit.

en	Records in TYPO3 can be configured to carry information about their language. If that is the case access to these elements will also be evaluated based on whether the user has the language in question included from this list. If a user has no languages listed all together it simply means that he can edit <em>all</em> languages!

en	be_users:allowed_languages

en	EXT:lang/cshimages/be_groups_18.png

en	This example shows a situation where two languages, Danish and German, are created in addition to the default language.

en	Select custom permission options.

en	This list represents custom permissions introduced by various backend modules (from extensions). The significance of each option depends on the backend module that evaluates it.

en	EXT:lang/cshimages/be_groups_20.png

en	This is just an example from an internal test application. It shows how checkboxes are added by a custom module under its own header. You can also show a description text with each checkbox to explain its function.