Follow-up for #1754246: Languages should be configuration entities

Problem/Motivation

Languages now configuration objects so their routers used own accessChecks

Proposed resolution

Implement all needed methods of LanguageAccessController for Language configurable entity and use it for all access checks on routes

#1946426: Convert all of confirm_form() in language.admin.inc to the new form interface
#2003592: Convert language_admin_add_form and language_admin_edit_form to a Controllers
#2005778: Convert language_admin_overview_form to a Controller

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

vijaycs85’s picture

Status: Active » Needs review
FileSize
1.92 KB

Initial patch....

vijaycs85’s picture

may need to close as this part covered in #2005778: Convert language_admin_overview_form to a Controller ?

andypost’s picture

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

We need list operation implementation so suppose better to make whole feature in #2005778: Convert language_admin_overview_form to a Controller
Let's use the issue to test patches to implement access controller with unittest

NW for

+++ b/core/modules/language/lib/Drupal/language/Controller/LanguageAccessController.phpundefined
@@ -0,0 +1,36 @@
+        $language = language_load($entity->id);
+        return !$language->locked && user_access('administer languages');

return !$entity->locked && user_access('adminster languages')

vijaycs85’s picture

Issue tags: -Needs tests

:D @andypost that's what happen when blindly convert ;) Thanks for the review. I have updated the overview page issue with your review comment in #3

vijaycs85’s picture

Issue tags: +Needs tests
YesCT’s picture

+++ b/core/modules/language/lib/Drupal/language/Controller/LanguageAccessController.phpundefined
@@ -0,0 +1,36 @@
+        return !$language->locked && user_access('administer languages');

Can we add an @see to the class (or something) where we define what locked is?

I remember it's the undefined and not applicable, but would be good to have a reference here, so we know why we do not allow editing or deleting those system (hidden) languages.

webflo’s picture

+++ b/core/modules/language/lib/Drupal/language/Controller/LanguageAccessController.phpundefined
@@ -0,0 +1,36 @@
+        return user_access('administer languages');
...
+        return !$language->locked && user_access('administer languages');

Pass $account to the user_access().

YesCT’s picture

Actually, someone could just look up that property, so we might not want an @see

...
When I looked up the property, I found no docs. :)
So:
#2035007: Add docs for properties in Drupal\Core\Language\Language

penyaskito’s picture

Status: Needs work » Needs review

#2005778: Convert language_admin_overview_form to a Controller landed, and includes a LanguageAccessController. Should we close this one? Are there any more tests needed?

Gábor Hojtsy’s picture

Status: Needs review » Closed (duplicate)

Looks like already resolved to me(?)

andypost’s picture

Title: Introduce an LanguageAccessController for Language entities » Implement checkCreateAccess on LanguageAccessController
Status: Closed (duplicate) » Needs review
Issue tags: -Needs tests
FileSize
680 bytes
andypost’s picture

Status: Needs review » Closed (duplicate)

Probably we could close the issue and implement the method in #2003592-15: Convert language_admin_add_form and language_admin_edit_form to a Controllers because the one depends on it.

andypost’s picture

Issue summary: View changes

Updated issue summary.