Access should be inherited from menu_item, not view access plugin.

I think the override/replacement actually happens in the views_menu_alter() code that runs after all view::execute_hook_menu() methods have been invoked to collate router items. Tough to override. :-/

Is the access plugin required? This should be the default behavior and only behavior. At least I cannot see why an admin-view would want to legitimately override/replace the router path access handling of the original item. The patch makes it look like we're already able to copy/retain the access definition?

Yeah, that's basically exactly my thinking -- The system display handler replaces an existing router item. If anyone wants to alter the router item, then he should use the known way for doing so; i.e., hook_menu_alter(). Injecting/adding a separate layer of access definitions, overrides, and alter hooks can only lead to problems (e.g., the admin-view uses its hard-coded permission instead of the actual definition in the router item, so any module that adjusts it, is tripped up).

Ideally, we should even go one step further and disable/remove the access configuration for views using the system display, so that this cannot even be configured in the Views UI. However, I don't know whether that is possible.

Actually, you might have been right with your original approach. However, for different reasons ;) (The access plugin code does not work, but I've documented what it is supposed to do)

+++ b/admin_views_default/taxonomy.admin-content-taxonomy.inc
@@ -13,14 +13,14 @@ $view->base_table = 'taxonomy_term_data';
-$view->disabled = TRUE; /* Edit this to true to make a default view disabled initially */
+$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

Let's revert this to disabled.

+++ b/plugins/views_plugin_display_system.inc
@@ -111,47 +111,16 @@ class views_plugin_display_system extends views_plugin_display {
+    // @todo Not required here, but we need to enforce the 'menu' access plugin for all admin_views.
+    // $access_plugin = views_get_plugin('access', 'menu');

Any idea how we can resolve that?

+++ b/plugins/views_plugin_display_system.inc
@@ -246,6 +215,11 @@ class views_plugin_display_system extends views_plugin_display {
+    // Disable access plugin in the UI.
+    // @todo Views plugins seem to be able to enforce options programmatically.
+    // $categories['access']['build']['#pre_render'] = array('devel_render');
+    $categories['access']['build']['#access'] = FALSE;

Actually, right before I uploaded my patch, I checked some of the other display plugins in Views, and based on those it appears to me that it should be possible for a display plugin to disable/hide + perhaps even enforce certain settings for itself.

I.e., it's possible that we don't need to hack + hide the access settings this way...

Thanks for reporting, reviewing, and testing! Committed to 7.x-1.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

err, forgot to mention that I adjusted/rewrote the code comments ;)

Dreditor doesn't support it yet, I'm using the MyWords add-on for Firefox. We have a docs page for collecting and optimizing stock responses: http://drupal.org/node/467548