Moves this class in an Odoo module so that other addons are able to
require and include the class in order to add different helpers.
This will be usefil in the `stock_barcode` module that will add a `scan`
helper.
Unlike LESS, SCSS variables are not lazy loaded. Our system has thus
to be updated. This commit creates new templates which are t-called
in assets bundles (to replace the old less_helpers template):
- web._assets_utils: regroups the mixins and functions which *can*
(and so should) be available in every asset bundle
- web._assets_primary_variables: regroups the variables (or mixins
used as variables) which *can* (and so should) be available in
every asset bundle
- web._assets_secondary_variables: same as above but provides an
environnement where all the 'primary' ones are accessible. This is
for example useful to handle the community/enterprise split:
// Community primary variables
$o-pink-color: pink; // enterprise color
$o-brand-primary: blue;
// Enterprise primary variables
$o-brand-primary: $o-pink-color;
// Community secondary variables
$o-my-darker-primary: darken($o-brand-primary, 5%);
=> If there was only one variable template, enterprise edition would
have been able to define its primary color at the end but the
darker primary would not have been updated. Using the "!default"
system and putting enterprise definition above would not have
solved the problem as the $o-pink-color would not have been
accessible.
- web._assets_backend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the backend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
- web._assets_frontend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the frontend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
Note: bootstrap variables are not accessible in any of those anymore.
If you have variables that should depend on bootstrap, you have 3
solutions:
- Find another way: your variable is probably useless, use bootstrap
variables directly or create a variable that will influence the
value of bootstrap variables. E.g. instead of declaring:
`$myvar: $bootstrapvar * 3`
and using $myvar alone, declare:
`$myvar: 3` and use `$myvar * $bootstrapvar` where needed.
- Declare a copy of the bootstrap variable and use that one. In that
case, you should also force-set the real bootstrap one to be sure
they match (this should be done in appropriate templates mentioned
above). E.g.
```
$o-boostrapvar: 5;
...
$boostrapvar: $o-bootstrapvar;
```
- Set your variable to null and set it to your bootstrap expression
in the file you will need it (where bootstrap variables are accessible)
without forgetting to add the !default flag to allow overriddes.
```
$myvar: null;
...
$myvar: $bootstrapvar * 5 !default;
```
This commit also partly changes the variable names to follow the
convention:
$o-<app_id>-<name> where 'app_id' is the current's app name or a
meaningful unique identifier ("theme" for all themes for example, as
no multiple themes can be installed).
Convert content so that the assets compile on app installation. The
style is still broken after this as the variables/mixins/... are not
defined in the right order (as it did not matter in LESS but does in
SCSS).
This commit basically changes:
- Variables: @var_hello -> $var-hello
- Mixins: .mixin_world() {} -> @mixin mixin-world {}
- Classes used as mixin: .my_class() -> @extend .my_class
- Here there were no other solution than to convert the use of
a mixin call by the use of an extend as a first approximation
- LESS functions -> SCSS functions (e.g. fade -> rgba)
- Move first variable definition before the variable is used
- Still need to make sure last variable definition is at the
right place
With this commit, any component that needs an instance of the
root widget can simply require the module 'root.widget'. Based on
the context (backend, frontend, iframe), the real root.widget
will resolve to either the webclient, the website root instance, or
the iframe root instance.
This is desirable in order for the tour_manager to become a child
of the root widget, as tours are enabled in any of the above contexts.
This commit is a requirement in order to solve an issue with JS services,
in which there should be only one service provider at any given time.
This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".
JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.
The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to
Summary of the changes:
- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed
A future improvement would be to translate some 'trigger' into 'trigger_up'.
In Less, the size_class XXS is defined and used in media queries.
This rev. adds it in JS for sake of consistency.
Code in addons comparing the size_class needed to be adapted due
to the new XXS size_class.
Moreover, we now use the helper 'config.device.isMobile' everywhere
we should, instead of manually comparing the size_class.
Finally, we changed the way the config.device has to be specified
in the test environment. From now on, only the size_class should be
set, and the isMobile flag is computed automatically.
This rev. makes the Rainbowman stop listening to event
'clear_uncommitted_changes' on core.bus, as this event is about to
be removed (in a next commit). It was using it to destroy itself
when such an event was triggered (basically, when the current view
was left).
Instead, we removed the option 'click_close' as, when set to true,
which was the default, the rainbowman was destroyed as soon as the
user clicked outside the raibowman.
Revert 6cb12273e2 which reverted
08d48b0fff.
Issue was the support for sub-parameters (aka @param {type} foo.bar)
where the "parent" parameter was not formal (only present in a
function's docstring, but not in the function's parameters list),
subtype creation would fail to find a root parameter to attach the
sub-parameter to.
This has not actually been fixed, but for the specific case where the
formal parameters list is *completely empty* we fall back on a list of
the docstring's parameters, which works well enough for this case.
Changed at 08d48b0ff but was crashing when building the documentation as not
complient for sphinx
Temporary fix that should be restored when our doc engine will be smarter
To consume a tip, the elements matching the selectors `trigger` and
`extra_trigger` must exist in the dom.
However, the presence of blockUI should prevent the tip to be consumed
in the tour because the user can't physically execute the corresponding action.
Bugs introduced with commit https://github.com/odoo/odoo/commit/08e92204b661086b27a2d435d3ca06436540c0e0
- The new `rainbowMan` option was always `true`
- When checking the option, it was looked in the wrong object so it was
always considered false (so no more rainbowMan at all...)
Also deactivate the rainbowMan for the automatic tours.
Also refactor the method's documentation.
With this commit, we add a few extra logs to help debugging issues with
phantomjs.
I suspect that the recent problems with phantomjs are due to the
localstorage not being cleared properly, but the logs are not sufficient
to determine the exact cause.
Simon Lejeune