0byt3m1n1
Path:
/
data
/
applications
/
aps
/
typo3
/
4.2.1-6
/
standard
/
htdocs
/
typo3
/
sysext
/
lang
/
[
Home
]
File: locallang_csh_be_groups.xml
<?xml version="1.0" encoding="utf-8" standalone="yes" ?> <T3locallang> <meta type="array"> <description>CSH for Backend Groups</description> <type>CSH</type> <csh_table>be_groups</csh_table> </meta> <data type="array"> <languageKey index="default" type="array"> <label index=".description">This is the Backend administration user groups available for the Backend users. These determine the access credentials for the Backend users.</label> <label index=".details">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.</label> <label index="_.seeAlso">be_users, "Inside TYPO3" about users / groups | http://typo3.org/documentation/document-library/doc_core_inside/Users_and_groups/, How to set up a backend user | http://typo3.org/documentation/document-library/doc_core_inside/Setting_up_a_new_use/, Setting up groups (from "Getting Started") | http://typo3.org/documentation/document-library/doc_tut_quickstart/Groups/</label> <label index="_.image">EXT:lang/cshimages/be_groups_2.png, EXT:lang/cshimages/be_groups_1.png</label> <label index=".image_descr">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.</label> <label index="title.description">Name of the Backend usergroup. The name should be descriptive and can always be changed later.</label> <label index="title.details">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.</label> <label index="_title.image">EXT:lang/cshimages/be_groups_2.png</label> <label index="title.image_descr">The usergroup title is shown in the record lists.</label> <label index="db_mountpoints.description">Define page tree root points for the group members.</label> <label index="db_mountpoints.details">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.</label> <label index="_db_mountpoints.seeAlso">be_groups:file_mountpoints, be_users:db_mountpoints, be_users:options, xMOD_csh_corebe:list_module</label> <label index="_db_mountpoints.image">EXT:lang/cshimages/be_groups_3.png, EXT:lang/cshimages/be_groups_4.png</label> <label index="db_mountpoints.image_descr">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.</label> <label index="file_mountpoints.description">Define startpoints for the file folder tree.</label> <label index="file_mountpoints.details">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 screen shots 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.</label> <label index="_file_mountpoints.seeAlso">be_groups:db_mountpoints, be_users:file_mountpoints, be_users:options, be_users, sys_filemounts, xMOD_csh_corebe:filelist_module, More about File Mounts | http://typo3.org/documentation/document-library/doc_core_inside/More_about_File_Moun/</label> <label index="_file_mountpoints.image">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</label> <label index="file_mountpoints.image_descr">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.</label> <label index="pagetypes_select.description">Select which 'Types' of Pages the members may set.</label> <label index="pagetypes_select.details">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.</label> <label index="_pagetypes_select.seeAlso">pages:doktype, be_groups:inc_access_lists</label> <label index="_pagetypes_select.image">EXT:lang/cshimages/be_groups_9.png</label> <label index="pagetypes_select.image_descr">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.</label> <label index="tables_modify.description">Select which tables the members may modify.</label> <label index="tables_modify.details">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.</label> <label index="_tables_modify.seeAlso">be_groups:tables_select, be_groups:inc_access_lists, xMOD_csh_corebe:new_ce</label> <label index="_tables_modify.image">EXT:lang/cshimages/be_groups_10.png, EXT:lang/cshimages/be_groups_15.png, EXT:lang/cshimages/be_groups_11.png</label> <label index="tables_modify.image_descr">The screen shot above shows how the "Create new record" dialog looks for a user limited to editing only "Page" and "Pagecontent" 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.</label> <label index="tables_select.description">Select which tables the members may see in record lists ('modify' tables does not need to be re-entered here!).</label> <label index="tables_select.details">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.</label> <label index="_tables_select.seeAlso">be_groups:tables_modify, be_groups:inc_access_lists</label> <label index="non_exclude_fields.description">Certain table fields are not available by default. Those fields can be explicitly enabled for the group members here.</label> <label index="non_exclude_fields.details">"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.</label> <label index="_non_exclude_fields.seeAlso">be_groups:inc_access_lists, Examples from "Getting Started" | http://typo3.org/documentation/document-library/doc_tut_quickstart/Groups/</label> <label index="_non_exclude_fields.image">EXT:lang/cshimages/be_groups_14.png</label> <label index="hidden.description">Disables a user group.</label> <label index="hidden.details">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.</label> <label index="lockToDomain.description">Enter the host name from which the user is forced to login.</label> <label index="lockToDomain.details">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.</label> <label index="_lockToDomain.seeAlso">be_users:lockToDomain, fe_users:lockToDomain, fe_groups:lockToDomain</label> <label index="groupMods.description">Select available backend modules for the group members.</label> <label index="groupMods.details">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.</label> <label index="_groupMods.seeAlso">be_users:userMods, be_groups:inc_access_lists, Backend Interface | http://typo3.org/documentation/document-library/doc_core_inside/Backend_interface/</label> <label index="_groupMods.image">EXT:lang/cshimages/be_groups_12.png, EXT:lang/cshimages/be_groups_13.png</label> <label index="groupMods.image_descr">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 screen shot 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.</label> <label index="inc_access_lists.description">Select whether the Access Lists for Page type, Tables, Module and Allowed excludefield are enabled for this group.</label> <label index="inc_access_lists.details">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.</label> <label index="_inc_access_lists.seeAlso">be_groups:pagetypes_select, be_groups:tables_modify, be_groups:tables_select, be_groups:groupMods, be_groups:non_exclude_fields</label> <label index="description.description">Enter a short description of the user group, what it is for and who should be members. This is for internal use only.</label> <label index="_description.seeAlso">fe_groups:description</label> <label index="TSconfig.description">User TSconfig: Additional configuration through TypoScript style values (Advanced).</label> <label index="TSconfig.details">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, show shortcut frame, 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).</label> <label index="TSconfig.syntax">TypoScript syntax without conditions and constants.</label> <label index="_TSconfig.seeAlso">be_users:TSconfig fe_users:TSconfig fe_groups:TSconfig pages:TSconfig, TSconfig Reference| http://typo3.org/documentation/document-library/doc_core_tsconfig/User_TSconfig/, TypoScript Syntax | http://typo3.org/documentation/document-library/doc_core_ts/</label> <label index="_TSconfig.image">EXT:lang/cshimages/be_groups_16.png, EXT:lang/cshimages/be_groups_17.png</label> <label index="TSconfig.image_descr">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.</label> <label index="hide_in_lists.description">This option will prevent the user group from showing up in lists, where user groups are selected.</label> <label index="hide_in_lists.details">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.</label> <label index="subgroup.description">Select backend user groups which are automatically included for members of this group.</label> <label index="subgroup.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.</label> <label index="explicit_allowdeny.description">Select field values to explicitly deny or allow for user group members.</label> <label index="explicit_allowdeny.details">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.</label> <label index="_explicit_allowdeny.image">EXT:lang/cshimages/be_groups_19.png</label> <label index="allowed_languages.description">Select which record languages the group members are limited to edit.</label> <label index="allowed_languages.details">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!</label> <label index="_allowed_languages.seeAlso">be_users:allowed_languages</label> <label index="_allowed_languages.image">EXT:lang/cshimages/be_groups_18.png</label> <label index="allowed_languages.image_descr">This example shows a situation where two languages, Danish and German, are created in addition to the default language.</label> <label index="custom_options.description">Select custom permission options.</label> <label index="custom_options.details">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.</label> <label index="_custom_options.image">EXT:lang/cshimages/be_groups_20.png</label> <label index="custom_options.image_descr">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.</label> </languageKey> </data> </T3locallang>