I wonder how it is possible to change the default settings for creating new users. At the moment I must remove the “live edit” permission and change the BE language to german for every single user.
I have two groups for my users AUTHOR and MAINAUTHOR. Members of AUTHOR should only have access to the draft workspace and only MAINAUTHOR’s members should have the live workspace too. (MAINAUTHOR inherits from AUTHOR and should add only the live permission.)
I found out that I can use setup.override.lang = de in the group options to change the language but I can’t find an equivalent for the live permission.
You can change the default pageTS for your own user via userTS (or for a whole group).
There you can use TCAdefaults to set default values for your be_users table.
https://docs.typo3.org/m/typo3/reference-tsconfig/11.5/en-us/PageTsconfig/TcaDefaults.html
Example from TYPO3 Core Docs for pages table
# Show newly created pages by default
TCAdefaults.pages.hidden = 0
You could try the extension sys_workflows[1] which was made for these kind of tasks. The extension should work on TYPO3 4.5 but doesn't work on a 6.2beta3 (just tested).
[1] http://forge.typo3.org/projects/extension-sys_workflows
You can configure the default values in the user TSconfig for new users. All options are described in the user TSconfig manual: https://docs.typo3.org/m/typo3/reference-tsconfig/11.5/en-us/UserTsconfig/Setup.html
Also explained is how to configure user TSconfig in general:
https://docs.typo3.org/m/typo3/reference-tsconfig/11.5/en-us/UsingSetting/UserTSconfig.html
Related
For my Trac plugin, I would like to add a color (as string or rgb values) to each user for use from somewhere else in the plugin. The color should be configurable via the admin page.
Is it possible to add another column to the table in the Users settings of the AccountManagerPlugin panel, and if it is, how do I add the information to the database so I can access it from elsewhere?
Another option would be to make a new Admin Panel for my plugin, which is what I am currently doing, with a table with just the user names and their colors. But in this case, although I already have the empty admin panel, I don't know how to add the table and add new items to the database.
To explain what I need the colors for:
My plugin adds a new export option for tickets, and formats them with my own html and css structure. The tickets contain the owner's name, and this name should be displayed with their respective colors. The code for this already exists, now I just need to retrieve the colors from the database, and beforehand save them to the database via the admin panel.
The colors should be changable only via the admin page.
There's no Users admin panel in Trac, however the AccountManagerPlugin has a User management panel. Let me know if you are using the AccountManagerPlugin and I'll provide more info on that.
Keeping the discussion within the scope of Trac, you could implement the ability for the user to make a selection through a preference panel by implementing IPreferencePanelProvider. You could save the value in the session_attribute table and make use of it anywhere else. For an attribute named user_color, the value can be retrieved using req.session.get('user_color').
Examples can be found in trac.prefs.web_ui. I've linked to the code in Trac 1.1.6 because the module was refactored so that the preferences were more modular #9162.
TCA offers the possibility for conditional displaying fields using displayCond. for an instance HIDE_FOR_NON_ADMINS allows to display field only for admin, but is there a way to display given field only for its creator, determined by cruser_id field?
Not out of the box. You can hook into TCEMAIN (DataHandler) or TCEFORM (FormEngine) to archive this.
You can however use access rights and set the rights to show the page (storage folder) only the the given backend user. Check out the access module.
I (as admin) want to create a few pages in the wiki where the users may/can create subpages or similiar hierarchical structures.
Is it possible to automatically create a hierarchical order (e.g. a few spaces like Tutorials / Info / Resources) and restrict the users from creating pages outside those defined areas?
I already tried to revoke edit rights from the users and use Structures and only granting rights to edit the content of the structures. This seems to work pretty well, but when a user creates a new sub pages he has no rights to edit them later, because the new files get the global rights (no edit permission).
Is there a right way to do that?
You can do this via Categories.
Create a category for each structure (Tutorials, Info, Resources).
Remove the global tiki_p_edit permission from the group, and edit the each category's permission to allow tiki_p_edit for that specific category.
Categorize each of the wiki pages within the appropriate structure.
Use the wiki "force categorization" option to automatically force newly created pages in the structure to be in the appropriate category.
I have an issue with a dotnetnuke 7 site, where the administrator cannot edit a minority of the pages.
When logged in and on such a page, the edit page menu missing.
When on the page management view, there are only options to view or make homepage. On clicking, properties are not shown.
What could be causing this?
Cheers, mark
I've seen in the past where the Administrator Role Id is incorrectly defined in the database.
Unfortunately there isn't a UI way to change this, you'll need to go into the DB to see what Role ID is defined. I believe AdministratorRoleID is stored either in the Portals table, or in the PortalSettings or PortalLocalization table. Check the # and see if that matches the ID of the Administrators role for that portal.
It could also be a CSS issue if it only affects some pages. Can you try changing the skin on those pages to the default skin and try again...
Just noticed this old question, so I thought that I'd update with what the actual problem was.
We imported pages using a direct to database program - we naturally assumed that the site administrator could, as a default be able to edit pages within their own site.
As it turns out, DNN actually creates correct access rights to each page as they are created, and rights are added and removed as required. This means that if you create pages you must directly create access rights for the correct site administrator.
Kind Regards, Mark, IA
How do I hide the content resource field from non-admin users?
So you'd like a user to be able to change document fields such as title, alias etc but not the content?
You can not lock individual fields to admin user (as far as I know). You can either lock the whole page/resource or you could put the content that you want to be locked into the template for that document and lock the template to only the admin user which would achieve the same effect.
Make sure you don't have a reference to [+content+] in the template and even if the user enters document content it won't impact the page.
New answer instead of editing the above as this is a much cleaner solution.
Create different user groups eg. Admin & Editor
Make sure admin is in the admin user group
Create a template variable for your content and in the Access Permissions section only tick the admin group.
Assign the TV to your template.
Now if the user isn't in the admin user group the TV won't even be visible when they are editing the resource.
Hey, thanks for the answer.
I thought I'd post what I ended up doing.
With MODx Evo 1+, you have managermanager included. After removing the included file(which is used rather than the default chunk) using the rules in there I can rename hide and sync content.