"You are not authorized to access this page." when I click on "Delete translation"

Hi lahode,

I had similar issue when I had the "Taxonomy translation" module turned on. Perhaps it's conflicting with ET.

I have this issue too. I've traced it through to EntityTranslationDefaultHandler::isTranslationForm(), where the language of the form is compared to the language of the term.

In my case, the isTranslationForm() was returning true for terms that aren't translations when the language of the term was undefined and the form was english.

The attached patch fixes the issue for me by returning false here if either the language of the term or the form is undefined.

Patch works for deleting.

Same happens tough when trying to edit/translate pre-existing terms. The translation tab disappeared and if I manually enter teh URL (en/taxonomy/term/26/transate) the same You are not authorized message pops up.

EDIT:
Looking at the db-entry - the reason seems to be that the language defined was set "und" instead of "en"

Hi,

I had this issue too when Taxonomy Translation was first activated and later on deactivated.

Some taxonomies were no translatebale any more by Entity Translation (no translate tab). Also the orginal language version (english) was not accesible when clicking the edit button. When clicking 'edit' on the original language version (english) I was immediatly redirected to a translated versions (french). Very odd.

To make the page available again for ET in the original language, I did the following:

• installed patch #3 against 7.x-1.0-beta3+14-dev
• went to entity translation configuration, made sure taxonomy vocabulary is translatable by Entity translation
• SAVED the configuration page to make all settings persistent (even if I didn't made changes)
• went to permissions page, checked if entity translation permissions are all set for the administrator
• edited the translated version of a problematic taxonomy
• this brought back the entity language selectors on top of the taxonomy edit page
• hit save on the original language version (english)

Voila, original language version is available again for Enity translation.
This took me almost 5 hours. Really glad I found your post :)))

Many thanks.

Hi guys,

I have the same problem for the contend in the webform module.
How can i apply this patch? Never needed to patch a module before...

*found a workaround.

Patch works for my project, thanks!

Adding related issue.

I was trying to use this patch on my project, for its Entity Translation module, but unsuccessful. I was unable to download the mentioned module by using drush command:

drush dl entity_translation-7.x-1.0-beta3+14-dev
Could not locate entity_translation version 7.x-1.0-beta3+14-dev.

I also tried to apply this patch to the current version of http://ftp.drupal.org/files/projects/entity_translation-7.x-1.0-beta4.ta..., and the http://ftp.drupal.org/files/projects/entity_translation-7.x-1.x-dev.tar.gz, but non of them was successfully patch applied, with a message saying there was something missing in the modules.

Any suggestions, would be highly appreciated

Daniel

@atpaust the patch still apply - did your try to read https://www.drupal.org/patch/apply Make sure you run 7.x-1.x-dev before applying the patch. This is my testing patch #3:

git apply -v ../entity_translation-isTranslationForm_2280567_3.patch
Checking patch includes/translation.handler.inc...
Hunk #1 succeeded at 1621 (offset 77 lines).
Applied patch includes/translation.handler.inc cleanly.

Thank you @steinmb, I appreciated your help.

So this patch will work with the newly upgraded 7.x-1.x-dev version, at http://ftp.drupal.org/files/projects/entity_translation-7.x-1.x-dev.tar.gz, right ?

Daniel

I have a related but not the same issue. I could not "Save and translate" terms - I got Access denied message "You are not authorized to access this page"
The answer is easy but well hidden!
In the Entity translation UI admin/config/regional/entity_translation select the Term you want to translate and you'll see a box that is ticked by default "Hide language selector". Untick this, and voila, you can select the appropriate language on your term edit screen and translate it.
Hope it helps someone.
Cheers

@teedave : thanks, that fixed my problem (same as yours)!
- However, I had to drush cc all, first.
- Then, edit some of my terms which had been set to "language neutral" (reason why they couldn't be translated, I guess).
- After saving as your desired language, you can then translate the term.

I think this might be related to #2467509: Access Denied on edit / translate tabs of entity

Hello

I am actualizing from 7.x-1.0-beta3+7-dev > 7.x-1.0-beta5 in a multilingual site and I've test this problem and I think that it is solved. I create a node, make a translation and deleted in the edit form. Please, could you check if you have problems and like that we facilitate a bit the work for planch? Thanks for your contributions :)

Yep, an update on this would be welcome, thanks. Btw, an update to the issue summary with proper steps to reproduce the issue, if it is not fixed now, would be even more welcome, see https://www.drupal.org/project/entity_translation#bugfixing.

Patch does not work for me and version 7.x-1.0-beta5+0-dev

So, I can't access the taxonomy term translation table unless I disable the Entity Translation module. Translate tabs then reappear and I no longer get the "access denied" message.

That's for taxonomy terms that existed before the installation of ET. For new terms with the module enabled, I can get to the term's translation table but with a "no translatable field" message for each language. The only way to get access to the translation table with translation enabled through the translate tab is to disable the module. All works well then.

I have the same problem, but found a workaround. You can still delete taxonomy terms using the Taxonomy Manager module: https://www.drupal.org/project/taxonomy_manager

@radioflyer: There is a patch that may solve your problem. It did for me.
https://www.drupal.org/node/1661348

I am having the same issue, please guide me how to upload the patch#3, I'm using 7.50

@refai85 What version of entity translation are you on? Can you also provide information about how to reproduce this?

Re-rolled #3 to entity_translation 7.x-dev from git (tested on Drupal 7.53.
Used #5 as method

Problem solved.

To the original issue..., it seems the access argument is wrong. Patch attached.

@vitalie: that's a really good observation, but I wouldn't touch that line, unless @plach thinks otherwise. It seems to have sth to do with #1661348: I18n Taxonomy integration. Some more background:
a) The 'access_arguments' property is set to point - correctly - to the '%taxonomy_term' autoloader wildcard
when entity-type-specific menu alterations are called, in this case entity_translation_taxonomy_term_menu_alter()
b) Your patch (#24) modifies what was part of fixing this issue #1661348: I18n Taxonomy integration and specifically, part of this commit (7a45648). So, we need some good reason for reverting that change that solves another issue.

@idevit: Thanks for the patch, but it needs to be applicable and pass the tests before we can look at it.

This issue was originally about a 'delete path' menu router item that is not accessible.
We need clear steps on how to reproduce that specific problem.
If you are having a different kind of problem, please open a new issue.

@stefanos.petrakis, sorry, did not catch that history behind it. I am not sure if "I do not have i18n_taxonomy module installed" is good enough a reason. If one has to have that module to make Delete work, it should be a dependency for entity_translation. I guess, that's also how you can reproduce it - do not install i18n_taxonomy and try to delete a translation.

What can be done then?

Hmm, well here's patch #24 with an extra switch. Maybe this can work?

@stefanos.petrakis, so I looked into point a):

a) The 'access_arguments' property is set to point - correctly - to the '%taxonomy_term' autoloader wildcard when entity-type-specific menu alterations are called, in this case entity_translation_taxonomy_term_menu_alter()

In fact, this is not happening, the access arguments property is not being set correctly. The 'delete' callback is only being set, with wrong access arguments, in entity_translation_menu_alter(), however entity_translation_taxonomy_term_menu_alter() does not alter it.

I better stop my attempts at patches, before you can comment.

Hey @vitalie, thanks so much for taking the time, let's get this bug!

First of all, it sounds as if you can reproduce the 'delete path' access problem (trying to be specific here).
I, from my side, cannot. So, I need your help to figure out how to.

Here is how I check that the menu items are correctly populated (this can evolve into a simpletest).

// Set up a standardprofile-based instance, install entity_translation 7.x-1.x-dev.
drush si standard --site-name='Entity Translation' -y && drush dl -y entity_translation-7.x-1.x-dev && drush en -y entity_translation
// This script activates Entity translation for taxonomy_terms, rebuilds the menu and print the 'translate path' and 'delete path'
drush scr et_menu_alter_analyze.php

The et_menu_alter_analyze.php is attached.

And here is the output I get after running this on my terminal:

root@etb5:/www/docroot# drush scr raks.php 
Array
(
    [taxonomy/term/%/translate] => Array
        (
            [0] => entity_translation_taxonomy_term_tab_access
            [1] => 2
        )

)
Array
(
    [taxonomy/term/%/translate/delete/%] => Array
        (
            [0] => entity_translation_taxonomy_term_tab_access
            [1] => 2
        )

)

Could you run this script too on your side and share the results?
And then, could you tell me what steps I am missing in order to reproduce the problem?

Cheers!

Hey @stefanos.petrakis, I've tried the script and it does print same thing as you mention, however it has a bug!

Please replace the print_r with this:

print_r(array(
    $menu_item => array_merge(
      array($menu[$menu_item]['access callback']),
      $menu[$menu_item]['access arguments']
    ),
  ));

In fact, you can also search the menu.array file and see that access arguments for delete/% is array(1).

You're right, sorry about that.
However, after fixing the et_menu_alter_analyze.php script (attached for reference), I still get the correct results:

Array
(
    [taxonomy/term/%/translate] => Array
        (
            [0] => entity_translation_taxonomy_term_tab_access
            [1] => 2
        )

)
Array
(
    [taxonomy/term/%/translate/delete/%] => Array
        (
            [0] => entity_translation_taxonomy_term_tab_access
            [1] => 2
        )

)

Could you share your menu.array file for cross-checking?
I am attaching mine, around line 17252, you will see, what is also printed out on the terminal, the access argument is 2.

@stefanos.petrakis, I was running an older version of the entity_translation module. So sorry to waste your time. The bug I am experiencing was fixed here:

https://www.drupal.org/node/2885858

Changing the state, please ignore comments from #24 till this one.

Excellent, we sorted this out then.
And we both put some time into this, no worries.
Thanks for finding the related issue.

fixed by updating entity_translation to beta7