Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Customising the CMS

Correct way of setting security access to editors


Go to End
Reply

22 Posts   3552 Views

Avatar
heidgert

7 July 2009 at 9:01pm Community Member, 16 Posts

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?

Avatar
Ingo

10 July 2009 at 9:20am Forum Moderator, 801 Posts

> 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
Avatar
heidgert

11 July 2009 at 7:45am Community Member, 16 Posts

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.

Avatar
AlexBeka

19 August 2009 at 10:31pm Community Member, 21 Posts

i have the same problem as heidgert; is there already a fix/patch available?

Avatar
wmk

19 August 2009 at 10:37pm Community Member, 45 Posts

Hi Ingo,

Same Problem here after installing the patch...

Avatar
Kalileo

5 October 2009 at 9:45pm (Last edited: 5 October 2009 9:48pm), Community Member, 127 Posts

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. [url=http://www.silverstripe.org/general-questions/show/270303#post270303]Content Admins need 'full administrative rights' to access and edit pages in the second language (Translatable)?[/url]

Avatar
Ingo

5 October 2009 at 11:18pm Forum Moderator, 801 Posts

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.

Avatar
AlexBeka

6 October 2009 at 2:05am (Last edited: 6 October 2009 3:20am), Community Member, 21 Posts

a quick patch for this issue:
replace the line

return i18n::get_locale_name( Translatable::get_current_locale() );

in function LangSelector() in CMSMain.php by:

$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?

Go to Top