openstack/horizon
Code Issues Proposed changes

doc: cleanup formatting

Browse Source 
* Clean up unnecessary vertical quotes at the left side
  caused by extra spaces at the beginning of lines.
* Do not use backquotes in the title lines
  (ref/run_tests.rst, ref/horizon.rst)
  When backquotes are used in the first-level title,
  it will be included in the navigation at the top-right corner
  https://docs.openstack.org/developer/horizon/contributor/ref/index.html
* Remove duplicated contents:: directive in ref/run_tests.sh.
  openstackdocstheme generates the toc by default, so having contents::
  directive leads to duplicated toc in a page.

Change-Id: Icc641927ad7cd7a8d79632c64a3ce212f0dc0b64
This commit is contained in:
Akihiro Motoki 2017-06-29 14:40:30 +09:00
parent 614bc7600a
commit 563908e2c0
17 changed files with 198 additions and 185 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
doc/source/contributor/contributing.rst
View File

@ -198,7 +198,8 @@ Required
* Use ``===`` as opposed to ``==`` for equality checks. The ``==`` will do a * Use ``===`` as opposed to ``==`` for equality checks. The ``==`` will do a
type cast before comparing, which can lead to unwanted results. type cast before comparing, which can lead to unwanted results.
.. Note :: .. note::
If typecasting is desired, explicit casting is preferred to keep the If typecasting is desired, explicit casting is preferred to keep the
meaning of your code clear. meaning of your code clear.
@ -282,16 +283,18 @@ Required
3. Avoid using classes for detection purposes only, instead, defer to 3. Avoid using classes for detection purposes only, instead, defer to
attributes. For example to find a div: attributes. For example to find a div:
::
<div class="something"></div> .. code-block:: html
$(".something").html("Don't find me this way!");
Is better found like: <div class="something"></div>
:: $(".something").html("Don't find me this way!");
<div data-something></div> is better found like:
$("div[data-something]").html("You found me correctly!");
.. code-block:: html
<div data-something></div>
$("div[data-something]").html("You found me correctly!");
* Avoid commented-out code. * Avoid commented-out code.
* Avoid dead code. * Avoid dead code.
@ -563,13 +566,13 @@ Conventions
Simply by convention, we have a few rules about naming: Simply by convention, we have a few rules about naming:
* The term "project" is used in place of Keystone's "tenant" terminology * The term "project" is used in place of Keystone's "tenant" terminology
in all user-facing text. The term "tenant" is still used in API code to in all user-facing text. The term "tenant" is still used in API code to
make things more obvious for developers. make things more obvious for developers.
* The term "dashboard" refers to a top-level dashboard class, and "panel" to * The term "dashboard" refers to a top-level dashboard class, and "panel" to
the sub-items within a dashboard. Referring to a panel as a dashboard is the sub-items within a dashboard. Referring to a panel as a dashboard is
both confusing and incorrect. both confusing and incorrect.
Release Notes Release Notes
============= =============

23
doc/source/contributor/intro.rst
View File

@ -15,12 +15,12 @@ Values
Horizon holds several key values at the core of its design and architecture: Horizon holds several key values at the core of its design and architecture:
* Core Support: Out-of-the-box support for all core OpenStack projects. * Core Support: Out-of-the-box support for all core OpenStack projects.
* Extensible: Anyone can add a new component as a "first-class citizen". * Extensible: Anyone can add a new component as a "first-class citizen".
* Manageable: The core codebase should be simple and easy-to-navigate. * Manageable: The core codebase should be simple and easy-to-navigate.
* Consistent: Visual and interaction paradigms are maintained throughout. * Consistent: Visual and interaction paradigms are maintained throughout.
* Stable: A reliable API with an emphasis on backwards-compatibility. * Stable: A reliable API with an emphasis on backwards-compatibility.
* Usable: Providing an *awesome* interface that people *want* to use. * Usable: Providing an *awesome* interface that people *want* to use.
The only way to attain and uphold those ideals is to make it *easy* for The only way to attain and uphold those ideals is to make it *easy* for
developers to implement those values. developers to implement those values.
@ -113,11 +113,6 @@ on the best possible experience.
.. seealso:: .. seealso::
:ref:`quickstart` * :ref:`quickstart` A short guide to getting started with using Horizon.
A short guide to getting started with using Horizon. * :ref:`faq` Common questions and answers.
* :ref:`glossary` Common terms and their definitions.
:ref:`faq`
Common questions and answers.
:ref:`glossary`
Common terms and their definitions.

15
doc/source/contributor/ref/forms.rst
View File

@ -88,11 +88,12 @@ That code would create the ``"switchable"`` control field ``source``, and the
two ``"switched"`` fields ``cidr`` and ``security group`` which are hidden or two ``"switched"`` fields ``cidr`` and ``security group`` which are hidden or
shown depending on the value of ``source``. shown depending on the value of ``source``.
.. note::
NOTE: A field can only safely define one slug in its ``"switch-on"`` attribute. A field can only safely define one slug in its ``"switch-on"`` attribute.
While switching on multiple fields is possible, the behavior is very hard to While switching on multiple fields is possible, the behavior is very hard to
predict due to the events being fired from the various switchable fields in predict due to the events being fired from the various switchable fields in
order. You generally end up just having it hidden most of the time by accident, order. You generally end up just having it hidden most of the time by
so it's not recommended. Instead just add a second field to the form and control accident, so it's not recommended. Instead just add a second field to the
the two independently, then merge their results in the form's clean or handle form and control the two independently, then merge their results in the
methods at the end. form's clean or handle methods at the end.

3
doc/source/contributor/ref/horizon.rst
View File

@ -41,5 +41,8 @@ Panel
.. autoclass:: Panel .. autoclass:: Panel
:members: :members:
Panel Group
===========
.. autoclass:: PanelGroup .. autoclass:: PanelGroup
:members: :members:

26
doc/source/contributor/ref/run_tests.rst
View File

@ -8,9 +8,6 @@ The run_tests.sh Script
Queens (13.0), in favor of tox. The tox docs can be found at Queens (13.0), in favor of tox. The tox docs can be found at
https://tox.readthedocs.io/en/latest/ https://tox.readthedocs.io/en/latest/
.. contents:: Contents:
:local:
Horizon ships with a script called ``run_tests.sh`` at the root of the Horizon ships with a script called ``run_tests.sh`` at the root of the
repository. This script provides many crucial functions for the project, repository. This script provides many crucial functions for the project,
and also makes several otherwise complex tasks trivial for you as a and also makes several otherwise complex tasks trivial for you as a
@ -23,10 +20,10 @@ If you start with a clean copy of the Horizon repository, the first thing
you should do is to run ``./run_tests.sh`` from the root of the repository. you should do is to run ``./run_tests.sh`` from the root of the repository.
This will do two things for you: This will do two things for you:
#. Set up a virtual environment for both the ``horizon`` module and #. Set up a virtual environment for both the ``horizon`` module and
the ``openstack_dashboard`` project using ``./tools/install_venv.py``. the ``openstack_dashboard`` project using ``./tools/install_venv.py``.
#. Run the tests for both ``horizon`` and ``openstack_dashboard`` using #. Run the tests for both ``horizon`` and ``openstack_dashboard`` using
their respective environments and verify that everything is working. their respective environments and verify that everything is working.
Setting up the environment the first time can take several minutes, but only Setting up the environment the first time can take several minutes, but only
needs to be done once. If dependencies are added in the future, updating the needs to be done once. If dependencies are added in the future, updating the
@ -48,14 +45,13 @@ Selenium tests by using the ``--with-selenium`` flag::
If you run horizon in a minimal installation VM, you will probably need If you run horizon in a minimal installation VM, you will probably need
the following (steps for Fedora 18 minimal installation): the following (steps for Fedora 18 minimal installation):
#. Install these packages in the VM: #. Install these packages in the VM:
``yum install xorg-x11-xauth xorg-x11-fonts-Type1.noarch``. ``yum install xorg-x11-xauth xorg-x11-fonts-Type1.noarch``.
#. Install firefox in the VM: #. Install firefox in the VM:
``yum install firefox``. ``yum install firefox``.
#. Connect to the VM by ``ssh -X`` #. Connect to the VM by ``ssh -X``
(if you run ``set|grep DISP``, you should see that the DISPLAY is set). (if you run ``set|grep DISP``, you should see that the DISPLAY is set).
#. Run #. Run ``./run_tests.sh --with-selenium``.
``./run_tests.sh --with-selenium``.
Running a subset of tests Running a subset of tests
------------------------- -------------------------

6
doc/source/contributor/ref/tables.rst
View File

@ -12,10 +12,10 @@ correctly and consistently, table-level and row-level actions all have a consist
API and appearance, and generally you don't have to reinvent the wheel or API and appearance, and generally you don't have to reinvent the wheel or
copy-and-paste every time you need a new table! copy-and-paste every time you need a new table!
.. seealso:: .. seealso::
For usage information, tips & tricks and more examples check out For usage information, tips & tricks and more examples check out
the :ref:`topics-datatables`. the :ref:`topics-datatables`.
DataTable DataTable
========= =========

6
doc/source/contributor/ref/workflows.rst
View File

@ -10,10 +10,10 @@ One of the most challenging aspects of building a compelling user experience
is crafting complex multi-part workflows. Horizon's ``workflows`` module is crafting complex multi-part workflows. Horizon's ``workflows`` module
aims to bring that capability within everyday reach. aims to bring that capability within everyday reach.
.. seealso:: .. seealso::
For usage information, tips & tricks and more examples check out the For usage information, tips & tricks and more examples check out the
:ref:`topics-workflows`. :ref:`topics-workflows`.
Workflows Workflows
========= =========

10
doc/source/contributor/topics/angularjs.rst
View File

@ -266,11 +266,11 @@ To use the automatic functionality, add::
to your enabled file (``enabled/<plugin_name>.py``). To make this possible, to your enabled file (``enabled/<plugin_name>.py``). To make this possible,
you need to follow some structural conventions: you need to follow some structural conventions:
- Static files should be put in a ``static/`` folder, which should be found directly under - Static files should be put in a ``static/`` folder, which should be found directly under
the folder for the dashboard/panel/panel groups Python package. the folder for the dashboard/panel/panel groups Python package.
- JS code that defines an Angular module should be in a file with extension of ``.module.js``. - JS code that defines an Angular module should be in a file with extension of ``.module.js``.
- JS code for testing should be named with extension of ``.mock.js`` and of ``.spec.js``. - JS code for testing should be named with extension of ``.mock.js`` and of ``.spec.js``.
- Angular templates should have extension of ``.html``. - Angular templates should have extension of ``.html``.
You can read more about the functionality in the You can read more about the functionality in the
:ref:`auto_discover_static_files` section of the settings documentation. :ref:`auto_discover_static_files` section of the settings documentation.

80
doc/source/contributor/topics/javascript_testing.rst
View File

@ -5,18 +5,19 @@ JavaScript Testing
================== ==================
There are multiple components in our JavaScript testing framework: There are multiple components in our JavaScript testing framework:
* `Jasmine`_ is our testing framework, so this defines the syntax and file
structure we use to test our JavaScript. * `Jasmine`_ is our testing framework, so this defines the syntax and file
* `Karma`_ is our test runner. Amongst other things, this lets us run the structure we use to test our JavaScript.
tests against multiple browsers and generate test coverage reports. * `Karma`_ is our test runner. Amongst other things, this lets us run the
Alternatively, tests can be run inside the browser with the Jasmine spec tests against multiple browsers and generate test coverage reports.
runner. Alternatively, tests can be run inside the browser with the Jasmine spec
* `PhantomJS`_ provides a headless WebKit (the browser engine). This gives us runner.
native support for many web features without relying on specific browsers * `PhantomJS`_ provides a headless WebKit (the browser engine). This gives us
being installed. native support for many web features without relying on specific browsers
* `ESLint`_ is a pluggable code linting utility. This will catch small errors being installed.
and inconsistencies in your JS, which may lead to bigger issues later on. * `ESLint`_ is a pluggable code linting utility. This will catch small errors
See :ref:`js_code_style` for more detail. and inconsistencies in your JS, which may lead to bigger issues later on.
See :ref:`js_code_style` for more detail.
Jasmine uses specs (``.spec.js``) which are kept with the JavaScript files Jasmine uses specs (``.spec.js``) which are kept with the JavaScript files
that they are testing. See the :ref:`js_file_structure` section or the `Examples`_ that they are testing. See the :ref:`js_file_structure` section or the `Examples`_
@ -32,11 +33,11 @@ Running Tests
Tests can be run in two ways: Tests can be run in two ways:
1. Open <dev_server_ip:port>/jasmine in a browser. The development server can be 1. Open <dev_server_ip:port>/jasmine in a browser. The development server can be
run with ``tox -e runserver`` from the horizon root directory. run with ``tox -e runserver`` from the horizon root directory.
2. ``tox -e npm`` from the horizon root directory. This runs Karma, 2. ``tox -e npm`` from the horizon root directory. This runs Karma,
so it will run all the tests against PhantomJS and generate coverage so it will run all the tests against PhantomJS and generate coverage
reports. reports.
The code linting job can be run with ``tox -e npm -- lint``, or The code linting job can be run with ``tox -e npm -- lint``, or
``tox -e npm -- lintq`` to show errors, but not warnings. ``tox -e npm -- lintq`` to show errors, but not warnings.
@ -66,14 +67,15 @@ Writing Tests
============= =============
Jasmine uses suites and specs: Jasmine uses suites and specs:
* Suites begin with a call to ``describe``, which takes two parameters; a
string and a function. The string is a name or title for the spec suite, * Suites begin with a call to ``describe``, which takes two parameters; a
whilst the function is a block that implements the suite. string and a function. The string is a name or title for the spec suite,
* Specs begin with a call to ``it``, which also takes a string and a function whilst the function is a block that implements the suite.
as parameters. The string is a name or title, whilst the function is a * Specs begin with a call to ``it``, which also takes a string and a function
block with one or more expectations (``expect``) that test the state of as parameters. The string is a name or title, whilst the function is a
the code. An expectation in Jasmine is an assertion that is either true or block with one or more expectations (``expect``) that test the state of
false; every expectation in a spec must be true for the spec to pass. the code. An expectation in Jasmine is an assertion that is either true or
false; every expectation in a spec must be true for the spec to pass.
``.spec.js`` files can be handled manually or automatically. To use the ``.spec.js`` files can be handled manually or automatically. To use the
automatic file discovery add:: automatic file discovery add::
@ -88,7 +90,8 @@ You can read more about the functionality in the
To manually add specs, add the following array and relevant file paths to your To manually add specs, add the following array and relevant file paths to your
enabled file: enabled file:
::
.. code-block:: python
ADD_JS_SPEC_FILES = [ ADD_JS_SPEC_FILES = [
... ...
@ -100,15 +103,17 @@ Examples
======== ========
.. Note:: .. Note::
The code below is just for example purposes, and may not be current in
horizon. Ellipses (...) are used to represent code that has been The code below is just for example purposes, and may not be current in
removed for the sake of brevity. horizon. Ellipses (...) are used to represent code that has been
removed for the sake of brevity.
Example 1 - A reusable component in the **horizon** directory Example 1 - A reusable component in the **horizon** directory
------------------------------------------------------------- -------------------------------------------------------------
File tree: File tree:
::
.. code-block:: none
horizon/static/framework/widgets/modal horizon/static/framework/widgets/modal
├── modal.controller.js ├── modal.controller.js
@ -117,7 +122,8 @@ File tree:
└── modal.spec.js └── modal.spec.js
Lines added to ``horizon/test/jasmine/jasmine_tests.py``: Lines added to ``horizon/test/jasmine/jasmine_tests.py``:
::
.. code-block:: python
class ServicesTests(test.JasmineTests): class ServicesTests(test.JasmineTests):
sources = [ sources = [
@ -135,7 +141,8 @@ Lines added to ``horizon/test/jasmine/jasmine_tests.py``:
] ]
``modal.spec.js``: ``modal.spec.js``:
::
.. code-block:: javascript
... ...
@ -204,7 +211,8 @@ Example 2 - Panel-specific code in the **openstack_dashboard** directory
------------------------------------------------------------------------ ------------------------------------------------------------------------
File tree: File tree:
::
.. code-block:: none
openstack_dashboard/static/dashboard/launch-instance/network/ openstack_dashboard/static/dashboard/launch-instance/network/
├── network.help.html ├── network.help.html
@ -215,7 +223,8 @@ File tree:
Lines added to ``openstack_dashboard/enabled/_10_project.py``: Lines added to ``openstack_dashboard/enabled/_10_project.py``:
::
.. code-block:: python
LAUNCH_INST = 'dashboard/launch-instance/' LAUNCH_INST = 'dashboard/launch-instance/'
@ -232,7 +241,8 @@ Lines added to ``openstack_dashboard/enabled/_10_project.py``:
] ]
``network.spec.js``: ``network.spec.js``:
::
.. code-block:: javascript
... ...

76
doc/source/contributor/topics/packaging.rst
View File

@ -16,11 +16,11 @@ to build the car, he must create the tool, too.
As a developer, if you are going to add a library named “foo”, the package As a developer, if you are going to add a library named “foo”, the package
must adhere to the following standards: must adhere to the following standards:
- Be a free package created with free software. - Be a free package created with free software.
- Include all tools that are required to build the package. - Include all tools that are required to build the package.
- Have an active and responsive upstream to maintain the package. - Have an active and responsive upstream to maintain the package.
- Adhere to Filesystem Hierarchy Standards (FHS). A specific file system - Adhere to Filesystem Hierarchy Standards (FHS). A specific file system
layout is not required. layout is not required.
Embedded copies not allowed Embedded copies not allowed
@ -146,16 +146,16 @@ maintainers. Some of the most important ones are:
- /usr is considered read only. Software must not write in /usr at - /usr is considered read only. Software must not write in /usr at
runtime. However, it is fine for a package post-installation script to write runtime. However, it is fine for a package post-installation script to write
in /usr. When this rule was not followed, distributions had to write many in /usr. When this rule was not followed, distributions had to write many
tricks to convince Horizon to write in /var/lib only. For example, tricks to convince Horizon to write in ``/var/lib`` only. For example,
distributions wrote symlinks to /var/lib/openstack-dashboard, or patched distributions wrote symlinks to ``/var/lib/openstack-dashboard``, or patched
the default local_settings.py to write the SECRET_KEY in /var. the default ``local_settings.py`` to write the ``SECRET_KEY`` in /var.
- Configuration must always be in /etc, no matter what. When this rule - Configuration must always be in /etc, no matter what. When this rule
was not followed, package maintainers had to place symlinks to was not followed, package maintainers had to place symlinks to
/etc/openstack-dashboard/local_settings in Red Hat based distributions ``/etc/openstack-dashboard/local_settings`` in Red Hat based distributions
instead of using directly instead of using directly
/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py ``/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py``
which Horizon expects. In Debian,the configuration file is named which Horizon expects. In Debian,the configuration file is named
/etc/openstack-dashboard/local_settings.py. ``/etc/openstack-dashboard/local_settings.py.``
Packaging Horizon Packaging Horizon
@ -168,29 +168,29 @@ Why we use XStatic
XStatic provides the following features that are not currently available XStatic provides the following features that are not currently available
by default with systems like NPM and Grunt: by default with systems like NPM and Grunt:
- Dependency checks: XStatic checks that dependencies, such as fonts - Dependency checks: XStatic checks that dependencies, such as fonts
and JavaScript libs, are available in downstream distributions. and JavaScript libs, are available in downstream distributions.
- Reusable components across projects: The XStatic system ensures - Reusable components across projects: The XStatic system ensures
components are reusable by other packages, like Fuel. components are reusable by other packages, like Fuel.
- System-wide registry of static content: XStatic brings a system-wide - System-wide registry of static content: XStatic brings a system-wide
registry of components, so that it is easy to check if one is missing. For registry of components, so that it is easy to check if one is missing. For
example, it can detect if there is no egg-info, or a broken package example, it can detect if there is no egg-info, or a broken package
dependency exists. dependency exists.
- No embedded content: The XStatic system helps us avoid embedding files that - No embedded content: The XStatic system helps us avoid embedding files that
are already available in the distribution, for example, libjs-* or fonts-* are already available in the distribution, for example, libjs-* or fonts-*
packages. It even provides a compatibility layer for distributions. Not packages. It even provides a compatibility layer for distributions. Not
every distribution places static files in the same position in the file every distribution places static files in the same position in the file
system. If you are packaging an XStatic package for your distribution, make system. If you are packaging an XStatic package for your distribution, make
sure that you are using the static files provided by that specific sure that you are using the static files provided by that specific
distribution. Having put together an XStatic package is *no* guarantee to distribution. Having put together an XStatic package is *no* guarantee to
get it into a distribution. XStatic provides only the abstraction layer to get it into a distribution. XStatic provides only the abstraction layer to
use distribution provided static files. use distribution provided static files.
- Package build systems are disconnected from the outside network (for - Package build systems are disconnected from the outside network (for
several reasons). Other packaging systems download dependencies directly several reasons). Other packaging systems download dependencies directly
from the internet without verifying that the downloaded file is intact, from the internet without verifying that the downloaded file is intact,
matches a provided checksum, etc. With these other systems, there is no way matches a provided checksum, etc. With these other systems, there is no way
to provide a mirror, a proxy or a cache, making builds even more unstable to provide a mirror, a proxy or a cache, making builds even more unstable
when minor networking issues are encountered. when minor networking issues are encountered.
The previous features are critical requirements of the Horizon packaging The previous features are critical requirements of the Horizon packaging
system. Any new system *must* keep these features. Although XStatic may mean system. Any new system *must* keep these features. Although XStatic may mean
@ -203,11 +203,11 @@ Packaging Horizon for distributions
Horizon is a Python module. Preferably, it is installed at the default Horizon is a Python module. Preferably, it is installed at the default
location for python. In Fedora and openSUSE, this is location for python. In Fedora and openSUSE, this is
/usr/lib/python2.7/site-packages/horizon, and in Debian/Ubuntu it is ``/usr/lib/python2.7/site-packages/horizon``, and in Debian/Ubuntu it is
/usr/lib/python2.7/dist-packages/horizon. ``/usr/lib/python2.7/dist-packages/horizon``.
Configuration files should reside under /etc/openstack-dashboard. Policy Configuration files should reside under ``/etc/openstack-dashboard``.
files should be created and modified there as well. Policy files should be created and modified there as well.
It is expected that ``manage.py collectstatic`` will be run during package It is expected that ``manage.py collectstatic`` will be run during package
build. build.

42
doc/source/contributor/topics/tables.rst
View File

@ -9,9 +9,9 @@ a convenient, reusable API for building data-driven displays and interfaces.
The core components of this API fall into three categories: ``DataTables``, The core components of this API fall into three categories: ``DataTables``,
``Actions``, and ``Class-based Views``. ``Actions``, and ``Class-based Views``.
.. seealso:: .. seealso::
For a detailed API information check out the :ref:`ref-datatables`. For a detailed API information check out the :ref:`ref-datatables`.
Tables Tables
====== ======
@ -26,13 +26,13 @@ Creating your own tables
Creating a table is fairly simple: Creating a table is fairly simple:
#. Create a subclass of :class:`~horizon.tables.DataTable`. #. Create a subclass of :class:`~horizon.tables.DataTable`.
#. Define columns on it using :class:`~horizon.tables.Column`. #. Define columns on it using :class:`~horizon.tables.Column`.
#. Create an inner ``Meta`` class to contain the special options for #. Create an inner ``Meta`` class to contain the special options for
this table. this table.
#. Define any actions for the table, and add them to #. Define any actions for the table, and add them to
:attr:`~horizon.tables.DataTableOptions.table_actions` or :attr:`~horizon.tables.DataTableOptions.table_actions` or
:attr:`~horizon.tables.DataTableOptions.row_actions`. :attr:`~horizon.tables.DataTableOptions.row_actions`.
Examples of this can be found in any of the ``tables.py`` modules included Examples of this can be found in any of the ``tables.py`` modules included
in the reference modules under ``horizon.dashboards``. in the reference modules under ``horizon.dashboards``.
@ -80,14 +80,14 @@ take place; prior to data being loaded into the table, and after the data
is loaded. When you're using one of the pre-built class-based views for is loaded. When you're using one of the pre-built class-based views for
working with your tables the pseudo-workflow looks like this: working with your tables the pseudo-workflow looks like this:
#. The request enters view. #. The request enters view.
#. The table class is instantiated without data. #. The table class is instantiated without data.
#. Any "preemptive" actions are checked to see if they should run. #. Any "preemptive" actions are checked to see if they should run.
#. Data is fetched and loaded into the table. #. Data is fetched and loaded into the table.
#. All other actions are checked to see if they should run. #. All other actions are checked to see if they should run.
#. If none of the actions have caused an early exit from the view, #. If none of the actions have caused an early exit from the view,
the standard response from the view is returned (usually the the standard response from the view is returned (usually the
rendered table). rendered table).
The benefit of the multi-step table instantiation is that you can use The benefit of the multi-step table instantiation is that you can use
preemptive actions which don't need access to the entire collection of data preemptive actions which don't need access to the entire collection of data
@ -262,10 +262,10 @@ functionality, communication with the server goes through AJAX in JSON format.
The javascript wrapper for inline editing allows each table cell that has The javascript wrapper for inline editing allows each table cell that has
in-line editing available to: in-line editing available to:
#. Refresh itself with new data from the server. #. Refresh itself with new data from the server.
#. Display in edit mode. #. Display in edit mode.
#. Send changed data to server. #. Send changed data to server.
#. Display validation errors. #. Display validation errors.
There are basically 3 things that need to be defined in the table in order There are basically 3 things that need to be defined in the table in order
to enable in-line editing. to enable in-line editing.

2
doc/source/contributor/topics/testing.rst
View File

@ -89,7 +89,7 @@ Cons:
* Did I mention that setting it up is a pain? * Did I mention that setting it up is a pain?
Screenshot directory could be set through horizon.conf file, default value: Screenshot directory could be set through horizon.conf file, default value:
"./integration_tests_screenshots" ``./integration_tests_screenshots``
So what should I write? So what should I write?
----------------------- -----------------------

4
doc/source/contributor/topics/workflows.rst
View File

@ -8,9 +8,9 @@ One of the most challenging aspects of building a compelling user experience
is crafting complex multi-part workflows. Horizon's ``workflows`` module is crafting complex multi-part workflows. Horizon's ``workflows`` module
aims to bring that capability within everyday reach. aims to bring that capability within everyday reach.
.. seealso:: .. seealso::
For detailed API information refer to the :ref:`ref-workflows`. For detailed API information refer to the :ref:`ref-workflows`.
Workflows Workflows
========= =========

5
doc/source/contributor/tutorials/dashboard.rst
View File

@ -592,6 +592,5 @@ What you've learned here is the fundamentals of how to write interfaces for
your own project based on the components horizon provides. your own project based on the components horizon provides.
If you have feedback on how this tutorial could be improved, please feel free If you have feedback on how this tutorial could be improved, please feel free
to submit a bug against ``Horizon`` in `launchpad`_. to submit a bug against ``Horizon`` in
`launchpad <https://bugs.launchpad.net/horizon>`__.
.. _launchpad: https://bugs.launchpad.net/horizon

5
doc/source/contributor/tutorials/table_actions.rst
View File

@ -296,6 +296,5 @@ snapshot to other API calls that require more complex forms to gather the
necessary information. necessary information.
If you have feedback on how this tutorial could be improved, please feel free If you have feedback on how this tutorial could be improved, please feel free
to submit a bug against ``Horizon`` in `launchpad`_. to submit a bug against ``Horizon`` in
`launchpad <https://bugs.launchpad.net/horizon>`__.
.. _launchpad: https://bugs.launchpad.net/horizon

25
horizon/tables/base.py
View File

@ -241,16 +241,23 @@ class Column(html.HTMLElement):
List of scope and rule tuples to do policy checks on, the List of scope and rule tuples to do policy checks on, the
composition of which is (scope, rule) composition of which is (scope, rule)
scope: service type managing the policy for action * scope: service type managing the policy for action
rule: string representing the action to be checked * rule: string representing the action to be checked
for a policy that requires a single rule check: for a policy that requires a single rule check,
policy_rules should look like policy_rules should look like:
"(("compute", "compute:create_instance"),)"
for a policy that requires multiple rule checks: .. code-block:: none
rules should look like
"(("identity", "identity:list_users"), "(("compute", "compute:create_instance"),)"
("identity", "identity:list_roles"))"
for a policy that requires multiple rule checks,
rules should look like:
.. code-block:: none
"(("identity", "identity:list_users"),
("identity", "identity:list_roles"))"
.. attribute:: help_text .. attribute:: help_text

24
openstack_dashboard/test/helpers.py
View File

@ -156,18 +156,18 @@ class TestCase(horizon_helpers.TestCase):
It gives access to numerous additional features: It gives access to numerous additional features:
* A full suite of test data through various attached objects and * A full suite of test data through various attached objects and
managers (e.g. ``self.servers``, ``self.user``, etc.). See the managers (e.g. ``self.servers``, ``self.user``, etc.). See the
docs for docs for
:class:`~openstack_dashboard.test.test_data.utils.TestData` :class:`~openstack_dashboard.test.test_data.utils.TestData`
for more information. for more information.
* The ``mox`` mocking framework via ``self.mox``. * The ``mox`` mocking framework via ``self.mox``.
* A set of request context data via ``self.context``. * A set of request context data via ``self.context``.
* A ``RequestFactory`` class which supports Django's ``contrib.messages`` * A ``RequestFactory`` class which supports Django's ``contrib.messages``
framework via ``self.factory``. framework via ``self.factory``.
* A ready-to-go request object via ``self.request``. * A ready-to-go request object via ``self.request``.
* The ability to override specific time data controls for easier testing. * The ability to override specific time data controls for easier testing.
* Several handy additional assertion methods. * Several handy additional assertion methods.
""" """
# To force test failures when unmocked API calls are attempted, provide # To force test failures when unmocked API calls are attempted, provide