| Age | Commit message (Collapse) | Author |
|---|
|
It has been decided to use Chart.js instead of nvd3 to render charts.
In this commit the graph view has been largely rewritten to benefit
from the options offered by Chart.js.
Task ID: 1946138
|
|
|
|
Currently tooltip goes out off the screen when the
graph view (in line mode) presents a large number
of groups.
The present commit splits the tooltip content in
three columns when the number of groups exceeds
20. This split is not done in mobile mode because
it is not an appropriate in that situation.
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Related to Task: 1917958
closes odoo/odoo#30288
|
|
In graph line mode, min and max abs are
displayed beyond the screen when there are less
than 3 abs.
This is happening because nvd3 fixes their
text-anchor to 'middle'. The present commit fixes
correctly their text-anchors to start and end
respectively by using the '!important' rule (it
seems difficult to do otherwise).
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Related to Task: 1917958
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
|
|
This commit improves UI of charts:
- Reduce margins of svg
- Put ticks label on right of y axis
- Bigger lines (line chart only)
- ligther area color (line chart only)
- Hide y axis line
- Force charts to begin at y=0
- Hide zero tick on y axes
There is no test because these changes only concerns visual effects.
Task ID: 1877588
|
|
A previous commit [333ac27] has introduced a new widget TimeRangeMenu
that allows to create two sets of data to compare relatively
to a given date or datetime field.
This commit allows the graph view to render appropriately two
sets of data as would be expected in the different modes.
Task Id: 1835644
|
|
מזל טוב
The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.
Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily
Adapt the css and views to be easier to switch direction
Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language
add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY
|
|
Completes commit https://github.com/odoo/odoo/commit/e10a4303c21332f10d89b0c19661cc11ca0dc7a6
|
|
In this commit, we extend the search view to allow the selection
of some intervals for date or datetime fields in groupby menu.
The valid intervals are day, week, month, quarter, and year.
It is also possible to add a button 'Group By' in the control panel
owned by a graph view in case it is declared 'embedded' (e.g. in a
dashboard view).
Note that have three new generic reusable widgets have been introduced
in this commit: DropdownMenu, GroupByMenu, and FiltersMenu.
|
|
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
|
|
This is a simple renaming without adaptation.
|
