89 lines
3.8 KiB
Python
Raw Normal View History

# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
import copy
from django.conf import settings
from django.test.utils import override_settings
import horizon
from openstack_dashboard.dashboards.admin.info import panel as info_panel
from openstack_dashboard.test import helpers as test
from openstack_dashboard.test.test_panels.plugin_panel \
import panel as plugin_panel
from openstack_dashboard.test.test_panels.nonloading_panel \
import panel as nonloading_panel
from openstack_dashboard.test.test_plugins import panel_config
from openstack_dashboard.utils import settings as util_settings
HORIZON_CONFIG = copy.deepcopy(settings.HORIZON_CONFIG)
INSTALLED_APPS = list(settings.INSTALLED_APPS)
# NOTE: Ensure dashboards and default_dashboard are not included in
# HORIZON_CONFIG to ensure warning messages from update_dashboards below.
HORIZON_CONFIG.pop('dashboards', None)
HORIZON_CONFIG.pop('default_dashboard', None)
HORIZON_CONFIG.pop('js_files', None)
HORIZON_CONFIG.pop('js_spec_files', None)
HORIZON_CONFIG.pop('scss_files', None)
util_settings.update_dashboards([panel_config,], HORIZON_CONFIG, INSTALLED_APPS)
@override_settings(HORIZON_CONFIG=HORIZON_CONFIG,
INSTALLED_APPS=INSTALLED_APPS)
class PanelPluginTests(test.PluginTestCase):
urls = 'openstack_dashboard.test.extensible_header_urls'
def test_add_panel(self):
dashboard = horizon.get_dashboard("admin")
Fix addition of plugin panel to panel group Revert fix from bug #1329050, which adds a plugin panel to its dashboard's class. Adding a plugin panel to a dashboard whose class has its panels defined in a tuple will fail because the new plugin cannot be appended to the tuple. The code errors out before the panel gets added to the dashboard's panel list. However, at this point, the panel has already been registered with the dashboard. This causes Dashboard.get_panels() to see the panel in its registry but not in its panel groups. Consequently, the panel gets put in the "Other" panel group instead of its configured one, as described in bug #1378558. By not adding the the plugin panel to its dashboard's class, the panel gets added to its dashboard's panel list. Now the original issue from bug #1329050 resurfaces. The root cause of that is that every time Dashboard._autodiscover() is called, it instantiates all its panel group classes, wiping out any panels previously added to any of the panel groups. Avoid this by always processing all the plugin panel groups before any of the plugin panels, which also ensures that the panel groups exist before their panels. Making this change exposed an issue where the Horizon URLs were being loaded twice during the plugin infrastructure's unit tests, causing plugin panels to be added multiple times to their dashboards. Fix that by removing the second, unnecessary call. Also create a second test plugin panel group and panel to test the scenarios described in the two bugs addressed here, adding two panel groups at a time. Change-Id: Id6a99c3ff18102c8f47431638d4dda98f14ec641 Closes-Bug: 1378558
2015-03-13 13:50:42 -07:00
panel_group = dashboard.get_panel_group('admin')
# Check that the panel is in its configured dashboard.
self.assertIn(plugin_panel.PluginPanel,
[p.__class__ for p in dashboard.get_panels()])
Fix addition of plugin panel to panel group Revert fix from bug #1329050, which adds a plugin panel to its dashboard's class. Adding a plugin panel to a dashboard whose class has its panels defined in a tuple will fail because the new plugin cannot be appended to the tuple. The code errors out before the panel gets added to the dashboard's panel list. However, at this point, the panel has already been registered with the dashboard. This causes Dashboard.get_panels() to see the panel in its registry but not in its panel groups. Consequently, the panel gets put in the "Other" panel group instead of its configured one, as described in bug #1378558. By not adding the the plugin panel to its dashboard's class, the panel gets added to its dashboard's panel list. Now the original issue from bug #1329050 resurfaces. The root cause of that is that every time Dashboard._autodiscover() is called, it instantiates all its panel group classes, wiping out any panels previously added to any of the panel groups. Avoid this by always processing all the plugin panel groups before any of the plugin panels, which also ensures that the panel groups exist before their panels. Making this change exposed an issue where the Horizon URLs were being loaded twice during the plugin infrastructure's unit tests, causing plugin panels to be added multiple times to their dashboards. Fix that by removing the second, unnecessary call. Also create a second test plugin panel group and panel to test the scenarios described in the two bugs addressed here, adding two panel groups at a time. Change-Id: Id6a99c3ff18102c8f47431638d4dda98f14ec641 Closes-Bug: 1378558
2015-03-13 13:50:42 -07:00
# Check that the panel is in its configured panel group.
self.assertIn(plugin_panel.PluginPanel,
[p.__class__ for p in panel_group])
# Ensure that static resources are properly injected
pc = panel_config._10_admin_add_panel
self.assertEqual(pc.ADD_JS_FILES, HORIZON_CONFIG['js_files'])
self.assertEqual(pc.ADD_JS_SPEC_FILES, HORIZON_CONFIG['js_spec_files'])
self.assertEqual(pc.ADD_SCSS_FILES, HORIZON_CONFIG['scss_files'])
self.assertEqual(pc.ADD_HEADER_SECTIONS,
HORIZON_CONFIG['header_sections'])
def test_extensible_header(self):
with self.settings(ROOT_URLCONF=self.urls):
response = self.client.get('/header/')
self.assertIn('sample context', response.content.decode('utf-8'))
def test_remove_panel(self):
dashboard = horizon.get_dashboard("admin")
Fix addition of plugin panel to panel group Revert fix from bug #1329050, which adds a plugin panel to its dashboard's class. Adding a plugin panel to a dashboard whose class has its panels defined in a tuple will fail because the new plugin cannot be appended to the tuple. The code errors out before the panel gets added to the dashboard's panel list. However, at this point, the panel has already been registered with the dashboard. This causes Dashboard.get_panels() to see the panel in its registry but not in its panel groups. Consequently, the panel gets put in the "Other" panel group instead of its configured one, as described in bug #1378558. By not adding the the plugin panel to its dashboard's class, the panel gets added to its dashboard's panel list. Now the original issue from bug #1329050 resurfaces. The root cause of that is that every time Dashboard._autodiscover() is called, it instantiates all its panel group classes, wiping out any panels previously added to any of the panel groups. Avoid this by always processing all the plugin panel groups before any of the plugin panels, which also ensures that the panel groups exist before their panels. Making this change exposed an issue where the Horizon URLs were being loaded twice during the plugin infrastructure's unit tests, causing plugin panels to be added multiple times to their dashboards. Fix that by removing the second, unnecessary call. Also create a second test plugin panel group and panel to test the scenarios described in the two bugs addressed here, adding two panel groups at a time. Change-Id: Id6a99c3ff18102c8f47431638d4dda98f14ec641 Closes-Bug: 1378558
2015-03-13 13:50:42 -07:00
panel_group = dashboard.get_panel_group('admin')
# Check that the panel is no longer in the configured dashboard.
self.assertNotIn(info_panel.Info,
[p.__class__ for p in dashboard.get_panels()])
Fix addition of plugin panel to panel group Revert fix from bug #1329050, which adds a plugin panel to its dashboard's class. Adding a plugin panel to a dashboard whose class has its panels defined in a tuple will fail because the new plugin cannot be appended to the tuple. The code errors out before the panel gets added to the dashboard's panel list. However, at this point, the panel has already been registered with the dashboard. This causes Dashboard.get_panels() to see the panel in its registry but not in its panel groups. Consequently, the panel gets put in the "Other" panel group instead of its configured one, as described in bug #1378558. By not adding the the plugin panel to its dashboard's class, the panel gets added to its dashboard's panel list. Now the original issue from bug #1329050 resurfaces. The root cause of that is that every time Dashboard._autodiscover() is called, it instantiates all its panel group classes, wiping out any panels previously added to any of the panel groups. Avoid this by always processing all the plugin panel groups before any of the plugin panels, which also ensures that the panel groups exist before their panels. Making this change exposed an issue where the Horizon URLs were being loaded twice during the plugin infrastructure's unit tests, causing plugin panels to be added multiple times to their dashboards. Fix that by removing the second, unnecessary call. Also create a second test plugin panel group and panel to test the scenarios described in the two bugs addressed here, adding two panel groups at a time. Change-Id: Id6a99c3ff18102c8f47431638d4dda98f14ec641 Closes-Bug: 1378558
2015-03-13 13:50:42 -07:00
# Check that the panel is no longer in the configured panel group.
self.assertNotIn(info_panel.Info,
[p.__class__ for p in panel_group])
def test_default_panel(self):
dashboard = horizon.get_dashboard("admin")
self.assertEqual('defaults', dashboard.default_panel)
def test_panel_not_added(self):
dashboard = horizon.get_dashboard("admin")
self.assertNotIn(nonloading_panel.NonloadingPanel,
[p.__class__ for p in dashboard.get_panels()])