Here is the story of the problem: back in 10.0, everything *seemed*
fine with button rendering except it was very messy duplicated codes.
The system was still not consistent:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> no class
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, outside the header, the system seemed to not process anything except
transforming the oe_highlight class. In the header, the btn-default was
always added, except if using the oe_highlight class. The style is fine
for those, except for .btn-default.btn-link and .btn-default.oe_link
where the link class has no effect (which is fine as header are not
supposed to contain links).
In 11.0, the new views were introduced alongside websitepocalypse. The
new system led to:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-default oe_highlight
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> oe_highlight
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, it worsened the header buttons by not processing the oe_highlight
class and adding the btn-default class in all cases. This is even
worse since in 11.0 .btn-default.btn-link do have a specific style and
thus not appear as .btn-default anymore. Those may be invisible "bugs"
though as .btn-link are not supposed to be in header and oe_highlight
is styled correctly in css. For buttons outside the header, a little
processing was added to add "btn-default" class for buttons which did
not specify a class (and oe_highlight is not processed anymore there
too).
In master, with the less2scss task, the system had to change again but
led this time to visible bugs:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
As you can see, the system is now the same for both header button and
normal buttons. The system is also better for all cases as it produce
only *one* *bootstrap* class for all cases. However, the problematic
case is the last one for header buttons: it did not receive the
btn-default class automatically. Even though this is the API for the
rest of odoo (dialogs, renderButton (old WidgetButton), ...), this is
a problem here as fixing this would require to add the 'btn-default'
class in every view which is using this case.
While waiting for a better solution, this commit is instead forcing
the btn-default class in that header case only (so only when a class
was mentioned but it did not contain any bootstrap btn type class).
So the new system gives:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
This commit also adds tests which will prevent the system to change
again without noticing it.
Closes https://github.com/odoo/odoo/pull/24443
The cover image top and bottom margins should be the same on a kanban record.
The bottom margin on `o_attachment_image` has thus been removed as it is already
defined on `o_kanban_record_body` class, which makes a double bottom margin.
Task 54019
Here is an interesting scenario, involving the reconciliation tour again
(because it is our only tour that does async stuff before changing url):
- web client starts normally
- tour reconciliation starts, perform an rpc to find some id
- web client fetches users default action, it is empty, so clicks on
first menu item to load initial action, which is discuss. this will
make the web client load the action with datamanager (it should be the
action manager's job!).
- reconciliation tour rpc completes, it changes the url, this will do a
do_action
- the load_action rpc from the web client completes, it will then
perform a do_action, which will drop the action initiated by the tour
- tour fails.
The issue here is that the on_menu_action method from the web client is
not really safe, from a concurrency point of view: it performs some
asynchronous work, and then unilateraly decides to do a doAction. With
this commit, we simply add the do_action request to the action manager,
which uses internally a "dropprevious" system. This means that it will
always use the last action, just as expected.
... by setting it 'btn-default', because users hesitate between
that button, and those in the control panel.
Task 32950
Co-authored-by: dbh <dbh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
Rev. 374af56 changed the way 'button' nodes are rendered in basic
views (form, list, kanban). As a consequence, their 'name'
attribute wasn't transmitted to the produced html elements anymore.
However, this attribute is very convenient to debug views, and to
write selectors in tests. For instance, it broke the test added by
rev. 8d17a2a once forwardported in master.
This commit reverts 1ce5bea.
This feature has been removed in rev. odoo/odoo@e533085 but this commit
reintroduces it. It was considered as "too dangerous" for new users.
Instead of removing the feature, a confirmation request has been added to warn
the user about his potentially harmful action.
The same warning has also been added in List view when archiving records.
Task 60393
Co-authored-by: Mohammed Shekha <msh@openerp.com>
When a user creates a new column in a kanban view, leave the action and
comes back, the order is not preserved. With this commit, we force a
call to resequence to ensure that the order does not change.
The initial rev. odoo/odoo@2d3ecf2 that was supposed to handle this use case
was in fact only dealing with one command as default value for nested x2m, not
more.
The basic model can now handle multiple commands.
Closes#24241
Since 11.0, reports could not be edited at all anymore. This is due to
the fact the editor files were refactored but the report feature is not
correctly organized since it was merged with the 'web' app. Indeed, the
'web' app is still calling files and assets of the 'web_editor' app which
is not a dependency (but it is working as 'web_editor' is auto-installed
with 'web').
opw-1826599
opw-1834971
Closes https://github.com/odoo/odoo/issues/24034
Before this commit, when uploading a file as attachment in Safari,
The file icon kept on showing 'downloading' whereas the request was successful
This was because the return from the server had a different UTF-8 norm than Safari
After this commit, it works well
OPW 1836545
closes#24307
Assume a list view with a many2many field, and a record for which
that many2many contains a single value, whose nameget returns the
empty string (which is a falsy value in JS). Before this rev., it
triggered an infinite number of namegets, and the browser crashed.
It was because the cell was re-rendered when the nameget returned,
and in the rendering of the cell, it re-performed a nameget if
the value was falsy.
opw 1838255d
and keep all those filters at last. (PR#20463)
e.g. If field used in color attribute of calendar view does not have value then such sidebar filters will not have string besides filter checkbox
in such cases we should set Undefined string and put all those filters at last in filter list
Currently we can see issue in calendar of manufacturing orders in db with demo data
Related to Issue #1778360
Co-authored-by: Mohammed Shekha <msh@openerp.com>
In some situations, it could happen that the action manager had a
rejected deferred representing the creation of a view, and was blocked
from doing any other interaction with that view.
For example, imagine that a read operation crashes for record 1 on the
model res.partner. If the user is on the kanban view and click on
record 1, there will be an error dialog informing him of the error.
However, if the user clicks then on another record, nothing will happen
because the action manager is blocked (only the form view in this case).
With this commit, whenever the view creation process failed, we also
remove the rejected deferred so the action manager will be allowed to
try again.
this.call('web.Notification', 'notify', params)
Display a notification at the appropriate location, and returns the
reference id to the same widget. Note that this method does not wait
for the appendTo method to complete.
@param {Object} params
@param {string} params.title notification title
@param {string} params.message notification main message
@param {string} params.type 'notification' or 'warning'
@param {boolean} [params.sticky=false] if true, the notification will stay
visible until the user clicks on it.
@param {string} [params.className] className to add on the dom
@param {function} [params.onClose] callback when the user click on the x
or when the notification is auto close (no sticky)
@param {Array<Object>} params.buttons
@param {function} params.buttons[0].click callback on click
@param {Boolean} [params.buttons[0].primary] display the button as primary
@param {string} [params.buttons[0].text] button label
@param {string} [params.buttons[0].icon] font-awsome className or image src
@returns {Number} notification id
this.call('web.Notification', 'close', notificationId)
Here is a scenario that could happen before this commit:
1. go to a list view with more than one record, say 3
2. click on the 3rd record to open the form view
3. the pager says 3/3
4. click on edit button
5. click on discard button
6. the pager says 1/3 (but the record displayed is still the same)
It is often necessary to restore the offset for the sub records, because
the number of pages in a one2many could have changed. However, it is
not a good idea to do that for the main record, since it interferes with
the usual flow of operations.
Currently, the default field widget of type html is not defined in the
web addon, but in the web_editor addon. It uses the summernote library
and different assets.
The web_editor addon is defined with auto_install=true, so it is usually
not an issue. However, it could happen that there is some issue with
the web_editor asset bundles. In that case, any form view with a field
of type html will crash.
With this commit, we define a default widget of type html in the web
addon. This will render as text (so, not exactly what one might
expect), but it is still better than making the web client unusable.
* mail, web, web_editor, website_sale
Tricky difference between LESS and SCSS:
`0 -$var` will be one value in SCSS (the result of 0 - $var) but
two space-separated values in LESS.
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).
During first scss convertion, classes called as mixins were changed to
an @extend instruction which was the best approximation given the fact
there is no equivalent in sass to do that. The problem is that the
instruction is slowing the scss computation a lot and might also break
the style in unexpected ways because of the complex unwanted selectors
the instruction induces.
This commit removes the need of extends. This is done case per case.
Sometimes this involves adding classes in xml, sometimes to change the
style a little, ... The button rendering refactoring which was made
at the start of the LESS to SASS merge was also done in prevision of
this.
After this commit, sass computation is like 5-6 times faster than less
computation while it was like 10 times *slower* before this commit.
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
Vincent Schippefilt