Jump to:

5513 Posts in 1732 Topics by 1218 members

Customising the CMS

SilverStripe Forums » Customising the CMS » Correct way of setting security access to editors

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Page: 1 2 3
Go to End
Author Topic: 3387 Views
  • heidgert
    Avatar
    Community Member
    16 Posts

    Correct way of setting security access to editors Link to this post

    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?

  • Ingo
    Avatar
    Forum Moderator
    801 Posts

    Re: Correct way of setting security access to editors Link to this post

    > 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
  • heidgert
    Avatar
    Community Member
    16 Posts

    Re: Correct way of setting security access to editors Link to this post

    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.

  • AlexBeka
    Avatar
    Community Member
    21 Posts

    Re: Correct way of setting security access to editors Link to this post

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

  • wmk
    Avatar
    Community Member
    45 Posts

    Re: Correct way of setting security access to editors Link to this post

    Hi Ingo,

    Same Problem here after installing the patch...

  • Kalileo
    Avatar
    Community Member
    127 Posts

    Re: Correct way of setting security access to editors Link to this post

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

  • Ingo
    Avatar
    Forum Moderator
    801 Posts

    Re: Correct way of setting security access to editors Link to this post

    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.

  • AlexBeka
    Avatar
    Community Member
    21 Posts

    Re: Correct way of setting security access to editors Link to this post

    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?

    3387 Views
Page: 1 2 3
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.