5102 Posts in 1520 Topics by 1116 members
| Go to End | Next > | |
| Author | Topic: | 2770 Views |
-
Correct way of setting security access to editors
7 July 2009 at 9:01pm
I'm using version 2.3.2 and have started to translate from english (EN_us) into two new languages - swedish (sv_SE) and german (de_DE).
This works very well for my own part, as an administrator, but I would like to set some restrictions for other people that will be allowed to translate (mainly for the german part since I will be translating into swedish myself).
What I basically want to do is the following:
1. Allow my editors access to the CMS - only the Site Content part.
2. Allow them to only translate a specific language. I have already created copies of every page that they should translate so they won't need to be able to edit the english pages.
3. Disallow them to publish pages, they should only be able to save drafts. (it would be good if they weren't allowed to remove pages also).
I have tried various approaches but haven't yet been able to succeed with this. Logging in with a user account that is member of my Editors group makes them able to change the english pages, but when navigating the tree in another language the main area becomes empty upon clicking a page in the site tree.
I need some advice on how to be able to correctly set this up. Could someone point me in the right direction?
-
Re: Correct way of setting security access to editors
10 July 2009 at 9:20am
> 1. Allow my editors access to the CMS - only the Site Content part.
There's permissions for this in the admin/security section (e.g. "Access SecurityAdmin")
> 2. Allow them to only translate a specific language. I have already created copies of every page that they should translate so they won't need to be able to edit the english pages.
There's a canTranslate() method which you could overload in Page.php.
You could check for membership in a specific group in there
to determine who's allowed to translate. There's some limitations around
the language dropdown above the sitetree, and in the "Translations" tab though,
they are transformed to readonly, which means you can't create translations in the first place.
If you have already created all translations, and just want editors to actually fill them with content,
you could point them to the direct language as a workaround, e.g. admin/?locale=de_DE
I've attached a small patch to Translatable.php (in trunk) which lets you configure this behaviour
through permission codes, but with the same limitations - it needs some more thought
around when to allow readonly-viewing of disallowed translations, when dropdowns should show values, etc.
Perhaps its helpful as a starting point, if you get anywhere we'd be happy to review core patches
> 3. Disallow them to publish pages, they should only be able to save drafts. (it would be good if they weren't allowed to remove pages also).
You can overload the SiteTree->canPublish() method in your Page class, and check for $this->Locale or other user permissions with Permission::check()
Attached Files-
Translatable.patch
1.6 KB
-
-
Re: Correct way of setting security access to editors
11 July 2009 at 7:45am
Thanks for your help!
The implementation of the PermissionProvider interface on the Translatable class is a really cool addition which will make my life much easier.
I seem to have run into a problem, though, which seems to be related to the ajax call on the click event on a page. I have reproduced this pattern on a fresh install with the default BlackCandy theme/demo site. This is my procedure and result:
1. Install a fresh site of SS v2.3.2.
2. Add the following lines to the _config.php file:
Object::add_extension('SiteTree', 'Translatable');
Translatable::set_default_locale('en_US');
$allowed_locales = array(
'en_US',
'sv_SE',
'de_DE'
);
Translatable::set_allowed_locales($allowed_locales);3. Run /dev/build
4. Log in to the cms with my admin account and create a new Security Group - "German translators", with one user - which I grant only "Access to 'Site Content' (CMSMain)".
5. Create a translation for the "Home" and "About us" page, in German.
6. Log out from the cms.
7. Log in using the account in the "German translators" group. I'll end up seeing the english site tree.
8. Click on the "Home" page, click the Translations tab and then the "German (Germany)" link under "Existing translations". I end up seeing the german site tree with the "Home" page in the main area. I do see the "original" field contents from the english translation - as expected - and I can also change anything and Save or Publish the page.
9. This is where the problem arises. Now I click on the "About us" page in the site tree. I will end up with an empty main area. Clicking on the "Home" page once again will not display it either. There is no way for me to get round this.
If I paste the exact link to the page in the address field (like http://localhost/admin/show/5 or another id), the page WILL show, just like in point 8 above.
My guess is that the ajax call when clicking a page in the tree somehow fails or something. Are you able to assist on this or should this be filed as a bug?
Please let me know if you want me to perform any additional task, like logging ur such. I'd be happy to help.
-
Re: Correct way of setting security access to editors
19 August 2009 at 10:31pm
i have the same problem as heidgert; is there already a fix/patch available?
-
Re: Correct way of setting security access to editors
19 August 2009 at 10:37pm
Hi Ingo,
Same Problem here after installing the patch...
-
Re: Correct way of setting security access to editors
5 October 2009 at 9:45pm Last edited: 5 October 2009 9:48pm
I see exactly the same problem as heidgert describes, and it could turn out to be a showstopper for the project I'm working on. Content Admins need 'full administrative rights' to access and edit pages in the second language (Translatable)?
-
Re: Correct way of setting security access to editors
5 October 2009 at 11:18pm
Looks like CMSMain->LanguageSelector should return a HiddenField with the locale value when the VIEW_LANGS permission is not provided. Anybody want to write a quick patch? I'm planning to replace the VIEW_LANGS permission with a TRANSLATE_<locale> and TRANSLATE_ALL permission set, as indicated in the patch above. Would that be useful? That'd mean there's no built-in distinction between viewing and editing a language, both are either provided or declined through TRANSLATE_. You could always be more specific in a overloaded canView() implementation though, and set allowed_locales() conditionally.
-
Re: Correct way of setting security access to editors
6 October 2009 at 2:05am Last edited: 6 October 2009 3:20am
a quick patch for this issue:
replace the linein function LangSelector() in CMSMain.php by:return i18n::get_locale_name( Translatable::get_current_locale() );
$literal = new LiteralField('LangSelector', "<input id=\"LangSelector\" type=\"hidden\" value=\"" . Translatable::get_current_locale() . "\" />" . i18n::get_locale_name(Translatable::get_current_locale()));
return $literal;is there a reason why the LanguageDropdownField in the function LangSelector() is only displayed if the user has the permission-code VIEW_LANGS but the LanguageDropdownField in the tab "Translations" is not checked against this permission-code?
| 2770 Views | ||
| Go to Top | Next > |
