My site currently has just English enabled, but we have entity_translate to allow the use of additional languages in future. I have a node that is written in 'und' that when I try to edit it I am told "Access Denied", "You are not authorized to access this page.".

The problem is in entity_translation_edit_access().

The call to entity_translation_form_language() return the language code 'en' because that is the language of the site. It doesn't bother checking to see if the content is written in that language, because the site is not multilingual.

Back in entity_translation_edit_access() it fails the check
(empty($translations->data) || isset($translations->data[$langcode]))
because while there is data (the first half), it is not in the correct language (second half).

The whole function seems a bit redundant on a single language site, so my suggested solution is just to skip it by adding the following at the top of the function.

  if (!drupal_multilingual()) {
    return TRUE;
  }
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

abautu’s picture

I can confirm this. Problem is that empty($translations->data) tests for "no locale" while in fact there is the und locale.

plach’s picture

Any patch?

abautu’s picture

Status: Active » Needs review
FileSize
855 bytes

I believe this would work.

Status: Needs review » Needs work

The last submitted patch, ticket_1860190.patch, failed testing.

abautu’s picture

Status: Needs work » Needs review
FileSize
708 bytes
Martijn Houtman’s picture

Same problem here, patch #5 works for me (latest dev).

ianthomas_uk’s picture

#5 is more working around the symptom rather than fixing the problem.

After further investigation the problem is actually that the call to entity_translation_form_language() is returning the wrong value. If I turn on a second language it checks for translations for both, finds neither and returns 'und', but if I only have one langauge then it won't bother checking for translations and will just return that.

Here is a patch for entity_translation_form_langauge() that:
a) Checks that a translation is available for the passed $langcode before returning it
b) Improves the readability of the function, particularly the $fallbacks loop

Reviewing entity_translation_edit_access() I don't think either of the last two if statements are required, as we now know that we're using a language that is supported by the entity, so we can go straight to the _entity_translation_callback. The comments don't make any sense to me, particularly "If translations have not been initialized yet, we need to grant access to the user." as there is no code following it to either grant or check language-specific access per-user. Does it make sense to anyone else?

plach’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

This has the potential to break things badly so we need to get it right. I'll have to review/test this thoroughly. It would be good to get some additional test coverage meanwhile.

Btw, there are some coding style issues with the patch: comments are missing the trailing dot and the are some trailing whitespaces above around the last lines.

Sheldon Rampton’s picture

I just tried the patch in #7 and it worked, but upon further investigation I discovered that the 7.x-1.x version of Entity Translation has refactored the entity_translation_form_language() functions so that the patch no longer cleanly applies. Fortunately, the refactoring seems to have fixed this bug anyway, so I think this ticket can probably be closed.

plach’s picture

Issue summary: View changes
Status: Needs work » Fixed

Ok, tentatively closing this, reopen if needed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.