In python3, super() does not always require a class and self reference.
In other words, super() is enough for most cases.
This is much simpler and it is time to switch it to the newer style.
pylint provides a check for this.
Let's enable 'super-with-arguments' check.
NOTE: _prepare_mappings() method of FormRegion in
openstack_dashboard/test/integration_tests/regions/forms.py is refactored.
super() (without explicit class and self referece) does not work when
a subclass method calls a same method in a parent class multiple times.
It looks better to prepare a separate method to provide a common logic.
Change-Id: Id9512a14be9f20dbd5ebd63d446570c7b7c825ff
six.reraise can be converted into "raise new_exc from original_exc"
introduced in python3.
In case of horizon.exceptions.handle(), six.reraise was used to
raise the original exception again, so we can convert it into "raise".
six is removed from requirements.txt.
Note that we need to keep six in lower-constraints.txt
as dependent libraries still use six.
Change-Id: I0672a516083727c245f1d4fa5b10eed9cd81a726
We don't support Python 2 anymore so we don't need this
compatibility library.
six.reraise usages are left as is until it'll be moved to some
base lib like oslo.utils to not re-implenent this method in
Horizon.
This patch also removes Python2-specific base test case methods
assertItemsEqual and assertNotRegexpMatches in flavor of new
Python 3 analogues.
Change-Id: I26a59176be9e9f213128e4945a58b9459334b626
In Train cycle, we moved the definition of default values
to openstack_dashboard/defaults.py. The current code accesses
a dict member using []. It requires operators to define a dict
setting with a full member.
This commit allows to use dict-type settings with partial members.
A new function is introduced to retrieve a dict-type setting
considering default values defined in
{openstack_dashboard,horizon,openstack_auth}/defaults.py
Change-Id: I7ff0ad4bca698aef9c0eba370b0570200a14367a
Closes-Bug: #1843104
Cookie-based settings related to openstack_dashboard are located
under horizon directory,, but they are not related to "horizon".
This commit moves them to "openstack_dashboard" directory.
Part of blueprint ini-based-configuration
Change-Id: Id48ececdbe819a95485e9a91dc5a1a163a5568c3
This commit enhances django workflow implementation to allow horizon
plugins to add workflow steps to a workflow in other repository like
the main horizon repo. New setting "EXTRA_STEPS" is introduced to
the horizon plugin 'enabled' file.
To this aim, the workflow class looks up HORIZON_CONFIG['extra_steps']
with its class full name and loads them as extra steps if any.
HORIZON_CONFIG['extra_steps'] are populated via horizon plugin settings.
This commit completes the blueprint.
blueprint horizon-plugin-tab-for-info-and-quotas
Change-Id: I347d113f47587932e4f583d3152e781ad1a4849f
W503 line break before binary operator
Looking at the code base, it sounds okay to follow this check.
Change-Id: Id511e0104dc6de5b204021661d4a8776ca6d3658
This patch allows Horizon to accept additional xstatic modules
in plugin dashboards. Related static files would be collected
and included in every page.
Change-Id: Ie49a522b28aaf6e028c5b218968d68189dd7eef1
Closes-Bug: #1755339
After futurist calls were introduced, the code became difficult to
understand. For example, local variables are used something like global.
To keep the code easier to understand, the usage of local variables
should be more scoped.
This commit introduces a wrapper function for futurist.ThreadPoolExecutor
and converts inline functions into normal methods.
I believe it improves the code readability a lot.
Change-Id: Id5b7a06c50e397c8c27447322d7f64f2d65c06b6
This commit enhances django tab implementation to allow horizon plugins
to add tabs to a tab group in other repository like the main horizon repo.
New setting "EXTRA_TABS" is introduced to the horizon plugin 'enabled' file.
To this aim, the tab group class looks up HORIZON_CONFIG['extra_tabs']
with its class full name and loads them as extra tabs if any.
HORIZON_CONFIG['extra_tabs'] are populated via horizon plugin settings.
This commit moves update_settings in openstack_dashboard.test.helpers
to horizon as I would like to use it in a new horizon unit test.
blueprint horizon-plugin-tab-for-info-and-quotas
Closes-Bug: #1746754
Change-Id: Ice2469a90553754929826d14d20b4719bd1f62d3
When doing theme customization with templates
collectstatic failes with a traceback
Change-Id: I0fdb80ddde1f73b657d445c75b55636d6f2e8d88
Closes-bug: #1744239
This patch also adds checks for executable files in
pep8 job.
nose ignores executable files by default, so it is important
to ensure executable flag is not set for test files [1].
openstack_dashboard/test/test_plugins/panel_tests.py was not
tested actually and it was broken. This commit fixes it too.
[1] http://nose.readthedocs.io/en/latest/usage.html#cmdoption-exe
Co-Authored-By: Ivan Kolodyazhny <e0ne@e0ne.info>
Change-Id: I3a124fa2f9f0676b2b43a094e32e3d8b18fa6005
This change allows to throw a detailed exception
in case if 'files' list has 'None' value:
"""
Exception occurred:
File "/<<PKGBUILDDIR>>/openstack_dashboard/utils/\
settings.py", line 263, in get_xstatic_dirs
for file in files:
TypeError: 'NoneType' object is not iterable
"""
Closes-Bug: #1732567
Change-Id: Iaf6282819c26c12ca24d19ef7dee00a5c8586418
This patch adds the infrastructure needed to move the configuration
of Horizon into oslo.config-compatible configuration file, instead of
the Django's Python-based configuration. It doesn't actually define
any configuration options, just the mechanism for loading them and the
additional types necessary to handle Horizon's complex configuration,
and the integration with oslo-config-generator.
Subsequent patches will add groups of options, making it possible to use
them in the local_settings.conf file instead of the local_settings.py
file. Note, that the options specified in the local_settings.py file
will continue to work.
Partially-Implements: blueprint ini-based-configuration
Change-Id: I2ed79ef0c6ac6d3816bba13346b7d001c46a7e80
This change is to introduce a flexible mechanism for projects to
add content to horizon's navbar.
- Introduces a new plugin file variable called ADD_HEADER_SECTIONS,
which will take a list of views. These are template views that
will be used to render individual header sections.
- There is a new view in openstack_dashboard/views.py to cycle
through these added views and combine them into the complete
header to be added to the navbar.
- This view is queried by newly added javascript after page load.
On response it is inserted into the page's navbar.
If more than one header is present, the first will be shown in
the navbar, while the rest are added to a drop-down menu.
- The currently displayed header can be changed by clicking on a
new header in the drop-down; this is stored in a cookie to
persist the selection between pages.
- Unit tests were modified/added to verify the new plugin entry
can be parsed successfully and the main header view can parse
a plugin's view successfully
Change-Id: I177b69ec4e78c17f827e540a7e669af1c29e8b59
Implements: blueprint extensible-header
Signed-off-by: Tyler Smith <tyler.smith@windriver.com>
At now, the horizon plugin framework does not allow to override default panel
settings by same filename. The embeded enabled files are always processed,
so this leads to make operators difficult to change the order of panels
from the default. In the original design of the plugin mechanism,
we allow to override embeded enabled files by local/enabled files.
For more detail, see bug 1700325.
This commit changes import_dashboard_config to override an embeded enabled
file by specifying a enabled file in local/enabled with the same filename.
Closes-Bug: #1700325
Change-Id: Id6b15848206a684eca850a8f510a8ba1608bb7bf
The Horizon spinner was using a spinner generated and animated
entirely out of JavaScript. Since CSS3 provides animates and we have
access to icon fonts, doing everything with JavaScript is not
necessary and actually taxing on the browser. Plus, all of the
spinner options were being passed in and around with JavaScript,
including the colors. This makes it supremely difficult to use the
theme to style the spinner.
The new spinner is just defined by a handful of templates now. There
are two clientside templates to support Legacy Horizon, and one
template in the Angular to support spinners going forward. Legacy
Horizon had two forms of spinners, so it was broken up. Angular as
not yet made use of the inline spinner, but should follow the same
markup when it is made.
There are two types of spinners, inline spinners (those shown when a
dynamic tab content is loading) and modal spinners (various other
places). These are consistent with each other for the 'default'
experience, but their experience can be entirely customized separate
from each other. 'material' has been augmented with loaders defined
within their design spec to show the power of this new feature.
horizon.templates.js was augmented with this refactor to support only
having to compile one tempalte at a time (instead of all of them) and
caching that template so that all of them can be recompiled later.
Also, horizon.loader.js was added to house template compilation code
that was repeated in several locations.
To test overwriting page modal spinner and inline-modal spinner
examples, please follow the instructions in _loading_inline_exmaple.html,
_loading_modal_example.html under
openstack_dashboard/themes/material/templates/horizon/client_side
Change-Id: I92bc786160e070d30691eeabd4f2a50d6e2bb395
Partially-implements: blueprint horizon-theme-css-reorg
Partially-Implements: blueprint bootstrap-html-standards
Closes-bug: #1570485
Since the existence of a domain token was equivalent with having
selected a domain context with Keystone V2, some code confuses the
two. This is no longer true for Kestone V3, so we have to separate
the two concepts and use domain context when we mean the domain
context.
Close-bug: #1661537
Change-Id: Ifa66d8c397e34d16a4534e7216eb11c752699505
As mentioned in [1], we should avoid using six.iteritems(iter) to
achieve iterators. We can use iter.items() instead, as it will
return iterators in PY3 as well.
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html
Change-Id: Ieadd5fa69b3f6058c0641a5b96ef3e8e1e3f6cc2
This patch reduces duplication arbitrary directory choices for
xstatic package locations in the static directory.
It moves the xstatic configuration from the library into the
settings file, and the supporting functions move to
the openstack_dashboard.utils.settings module. Having the xstatic
module list in settings allows deployers to add new modules.
It standardises the paths the files are served from, reducing
potential conflicts.
It simplifies the interaction with the xstatic modules, and also uses
the new MAIN variable if present to determine the entry points used.
Since some of the xstatic packages were installed into special
snowflakes directories (not following a pattern) the references to
those (bootstrap_scss and font_awesome) have been fixed.
Change-Id: Ia5be0e96fff1a4ddd6058d6b030ddf96da4b46e7
In dashboard or panel, 'openstack.roles.xxx' is used
as a permission control. 'xxx' in 'openstack.roles.xxx'
is a real role name.
At the moment, it is not addressed OPENSTACK_KEYSTONE_ADMIN_ROLES.
This patch will address it.
Change-Id: Ic7200dfdf403b63ef3210750617ae102b15c02c8
Closes-Bug: #1534409
A dashboard enabled file in local/enabled is not able to appear before,
or inbetween any core panels.
The list of panels appears to be intended to be sorted by file name,
but all files in /enabled and always presented in the nav ahead of
any files from local/enabled, no matter the file name.
This appears to be a bug in util/settings.py that does an rsplit to
separate file name from path, but accidentally uses the full list of
split items, instead of just the file name.
For example, a file with __name__ of
'openstack_dashboard.enabled._1040_project_volumes_panel' splits into
['openstack_dashboard.enabled', '_1040_project_volumes_panel']. When
this list is fed to cmp(), it will always come before a panel in
local/enabled such as
['openstack_dashboard.local.enabled', '_0001_my_new_panel']
Change-Id: Ic169ccf0db1e04ec42fe999df6648117ce9efe84
Closes-Bug: 1567047
Horizon still uses django.utils.importlib which is removed from Django
1.9. We should use:
from importlib import import_module
instead of:
from django.utils.importlib import import_module
Change-Id: I422e14546468cb9c5627e746023948aab107a338
Closes-Bug: #1534522
Partially-Implements: blueprint drop-dj17
Co-Authored-By: Rob Cresswell <robert.cresswell@outlook.com>
When we do "member update" on domain and project page,
'admin' role is used by fixed string in internal processing.
However, since kilo we can use OPENSTACK_KEYSTONE_ADMIN_ROLES
and it mean the list of roles that have administrator
privileges. So this patch modify to use this setting.
Change-Id: I3817b168e7ac448997f41c1a4f4b3a3606994297
Closes-Bug: #1527457
It's not possible for plugins to contribute translations to the javascript
message catalog. Right now our files are hardcoded to allow only
contributions from horizon and openstack_dashboard. This patch fixes
the issue.
Change-Id: Idde2fc6ac0bf7f762a595cf139ed5184dad64540
Closes-Bug: #1523930
This patch does three things:
1) It adds the extensible service which can be used to allow plugins
to customize various containers by adding and removing items such as
workflow steps, table actions, and form fields.
2) It adds support for a "feature" plugin that can be used to add
angular modules that can then be used to customize various panels.
The feature plugin is different from a typical plugin in that it does
not add a dashboard or panel, it only adds angular modules, JS files,
HTML templates, spec files, styles, etc.
3) It updates the workflow service to make each workflow extensible
and adds IDs to the launch instance workflow steps so that this
workflow instance is now extensible.
An example feature plugin is available here:
https://drive.google.com/open?id=0Bye7buoZvOxFOXJvMTNNUTdNNUk
Documentation will be provided by this commit:
https://review.openstack.org/244407
Implements: blueprint angular-workflow-plugin
Change-Id: I8b426b1644c26b1af063d570da19a75ac8c97c27
In some of the dashboard 'views.py' files, there is code that enables
the detail status and, when applicable, admin state labels to be
translated. The current coding style of these sections is hard
to read. Any and all sections of code that use this style should
be refactored to enhance the code readability. This change
proposes to create a single utility method that handles this
repetitive code block that is used in many places. Thus to perform
the translation label lookup, this method need only be called. This
method will provide a single clean and consistent code block that can
be used for any of these situations in the future.
Change-Id: I6353abef58fc2a481d4379eb1a2f8289d7f1790b
Closes-Bug: #1490031
The iteritems() method of Python 2 dictionaries was renamed to items()
on Python 3. The overhead of creating a temporary list for items() on
Python 2 is negligible.
Replace also dict.itervalues() with six.itervalues(dict) in
horizon/test/utils.py.
Partial-Implements: blueprint porting-python3
Change-Id: Ib2d62236be2620c4626099ce80e6c8a9397a4533
When AUTO_DISCOVER_STATIC_FILES enabled in a plugin dashboard,
static files including JavaScript files and static angular html
templates will be automatically discovered.
Change-Id: I7a88983f2604b71431b5b18c97a5c22c37961141
Partially-Implements: blueprint auto-js-file-finding
Users can add custom scss via the ADD_SCSS_FILES in enabled file.
Keeping the dashboard.scss for now, will remove in later patches.
Tests provided in a follow-on patch:
https://review.openstack.org/#/c/195781/
Co-Authored-By: Shaoquan Chen <sean.chen2@hp.com>
Implements: blueprint pluggable-scss
Change-Id: I34c7dd2a69eb194a0b28275baba49bdea3348f70
This change moves the controller ImageFormCtrl and
hzNamespaceResourceTypeFormController from horizon (the framework)
to openstack_dashboard (the application) where they belong.
Co-Authored-By: Tyr Johanson <tyr@hp.com>
Change-Id: I2309f0867c2f657a6065003475dcb10448f907bc
Partial-Bug: #1458697
The metering forms were using the date picker functionality from the
d3 line chart library, this used to work when it was loaded as a whole
page as the d3 libary would run intending to setup any d3 graphs however
now it is being loaded as a modal the elements that would be affected by
the d3 code do not exist at page load time.
In order to get the date picker events to be added to the elements on
the form when the modal loads, the JS in the forms template has been
extended in this patch to support adding those events.
This patch also changes the data attributes on the form elements so that
they do not conflict with any d3 line chart elements.
Alongside the javascript this patch fixes bug to do with parsing the
dates in metering utils and adds UTs to prevent regression.
Change-Id: I4e239daa03b2f54e434254bac48ba0cceb037b5d
Closes-Bug: 1427756
Currently we using a meter-list for getting a "unit" for metric.
Meter list get all available metric on environment,
it's may be a thousands of records.
It's better to use sample-list for this metric with "limit" 1.
This request gets a 1 sample for queried metric.
Change-Id: I4bf0ab7ebcbcae1ddc90d8ee01d5f5a84ed4fbba
Related-bug: #1444456
Defines a new option, ADD_INSTALLED_APPS, which gets prepended
to the beginning of INSTALLED_APPS.
Change-Id: I956835c3e18edee9e223a607005b47a5c5977687
Closes-bug: #1343342
Horizon has a well-defined plug-in architecture, but the
architecture doesn't cover Horizon's Jasmine spec runner.
This patch fills the gap.
This patch also
- defines a new field `js_spec_file` in HORIZON_CONFIG in settings.
- fix a bug openstack_dashboard/utils/settings.py where using python set
to collect js files, which will cause the order of the js file lost.
Change is made to use list to respect the js files order.
- update doc/source/topics/settings.rst to include the newly added field.
Change-Id: Idc122e8b1f917cdd344aa8f4b48fd80a6bdddb70
Close-Bug: 1421778
Akihiro Motoki