Consider a context-dependent field, and successively access it on a
recordset with different contexts. On the first context, the field is
correctly computed in batch. After that, the field is always computed
one by one.
The bug is in the method that determines which records in a given set
have no value in cache. On the first context, the cache is empty for
the field, so all records are returned. After that, the method
considers that all records have a value in cache: they do, but for
another context key! Simply using the context key when looking up the
cache fixes the issue.
closesodoo/odoo#52360
X-original-commit: 35d69589d9b43afe6c6fc9779458323f7180153e
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
Steps to reproduce the bug:
- Let's consider a customer company partner P
- Let's consider, P1, a child partner of P
- Create a SO for P1
- Archive P1
Bug:
The SO count in the smart button Sales of P was 0 instead of 1
opw:2267828
closesodoo/odoo#52340
X-original-commit: 31ded31dab5c389e6cb1b85f65e780a1e5ab5b28
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, a user with attendance administrator rights can see
the attendances of all users of all companies and not only the companies
he is allowed.
Now, the administrator will only see the attendances of the users of the
companies he is allowed.
opw-2263577
closesodoo/odoo#52355
X-original-commit: 0e8f86795db74fe21daa8776243415291371fdf6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Note : Manual forward port recovering from commit ae1e70eba10112170283cfc17fa95d94dd948d2b
Purpose
=======
Let's say that the field 'foo' is tracked and defined with a res.group.
When the field is modified, a mail.tracking.value is generated, but the
reference to the field name is a char field.
When displaying the mail.tracking.values on the chatter, a check is done
according to the field group to decide whether we should display it or not
to the user. See: c7aa8c5#diff-ad8b6db158187579d2208f233d993c3cR43
So if I rename the field, and if the mail.tracking.value is not modified,
the mail.tracking.value magically appears to the users who shouldn't
access it before.
Note: If the migration is correctly handled, this shouldn't be the case.
But manual manipulations on the database could lead to this issue.
Specification
=============
If the field referenced by the mail_tracking_value doesn't seem to exist,
then display its value to system users only, by security.
closes#39016closesodoo/odoo#52348
Taskid: 2088634
X-original-commit: 19bc081e4a71042c3f009e4af641da18fc16bdfe
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When installing sale_margin, the computed fields will be computed on existing
sale.order and sale.order.line in database. On huge databases, the computation
may take a lot of time, depending on the configuration (multi-company, multi-currency, ...)
The current commit improves the computation of the purchase_price
(recently changed to a computed field), by avoiding unnecessary currency
conversions when possible (one less query to get the conversion rates).
In a multi-currency database where the products have no cost defined
(standard_price field), the sale_margin installation takes up to 50% less time.
closesodoo/odoo#52338
X-original-commit: 3c9841d1aa4fc5b10012c8239a31d6e7f8676fc0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Installing sale_margin module on a db with a lot of sale.order was impossible.
This commit significantly improves performances.
Went from many hours (forecasted) to 15 minutes on a db with 300k orders
For sale.order:
- Duplicating logic between edit mode and non edit mode
- Edit mode logic stays the same as before
- Non edit mode uses read_group to speed up the computation
X-original-commit: 9f1ea7427cdb6984f175f5111e4c9a4c5f013af2
Before this commit, `self.env.user.company_id.id` may represents different company from the current company based on context.
In this commit, we use correct company based on contextual company.
Follow up on b39173a8ffclosesodoo/odoo#52328
X-original-commit: 2314ce8b3de80ff6c4c9dec35ea6a201f885ba16
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Close can now be requested by children (slot content) with the event
`o-popover-close`. This feature is necessary if we want a "close" button inside
the popover itself, which is the case for mail.activity "Mark Done".
Clicking on the popover target now acts as a toggle, which is also a feature
that was expected from the previous popover implementation.
Add a specific class (`o_is_open`) when the popover is displayed to be able to
style its target depending on whether it is displayed or not.
Ensure computed position is whole number of pixels to prevent flicker issue on
Firefox.
Remove forced width to let the component grow with its content.
Add appropriate z-index to prevent overlap issue with the rest of our interface.
closesodoo/odoo#50850
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the Start now button uses the first slide (a content
slide or a category slide). If the first slide was a category slide then
an error was raised.
Now, only content slides are used to start the survey.
opw-2265250
closesodoo/odoo#52309
X-original-commit: bbc84c5d03eae51b6edfe270da51087970db2227
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit attempts to fix the emoji widget position issue (only in enterprise versions) on mobile screen.
The emoji dropdown overflow & emojis font display issues (on mobile screen) are also fixed in this commit.
The following changes have been made :
1- Add css media-breakpoint to override widget position in small breakpoint and narrower.
2- Add position-relative + bottom css on widgets to avoid negative margins.
3- Set a max-width for the dropdown on mobile screen.
4- Add width/height on emoji icons to solve emojis position issue for some fonts (on different OSes > browsers).
This fix was made with the 'smallest possible changes' taking in consideration effects on :
- "text_emojis" widgets, since they use same class : "o_mail_emojis_dropdown".
- Emoji widget position in community (This fix won't break widget position in community version).
Task ID 2224393
closesodoo/odoo#52182
X-original-commit: 405e113e897b914eed41b34a66b5a7f740dcd336
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Create a bank journal, with "post at" = "Bank reconciliation"
- Create a new expense paid by "Company"
- Create a report and confirm
Current behavior:
- the bank move is posted
Expected behavior:
- the bank move is not posted (and i will posted during the bank reconciliation"
closesodoo/odoo#52260
X-original-commit: 0b45a8317f1e4538ad93aa169b8be08f5403340a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The *Reload File* import functionality stands on an undefined behavior
or the HTML File API. The API is not clear about what should done in
case the underlying file change on the filesystem after it has been
imported in the browser.
It turns out the actual behavior vary among browsers and even among
OSes. The *Reload File* button only works as intended when importing
files via Chrome on Linux.
In other cases, the browser may refuse to send the file or may send it
in a corrupted HTTP request. Such malformed request is rejected in the
best cases by the backend web application but there is chance it hangs.
Security-wise, this problem is not much likely to happen as it requires
an authenticated user with importation privileges to perform the
operation. When it comes to the severity, it is possible to exhaust the
available workers by forcing every one of them to hang.
As there is a security impact, we decided to disable the *Reload File*
functionality.
Steps to reproduce
------------------
1) Import a CSV or XLSX document in any model.
2) Wait for the data visualization to come back to the browser.
3) Change the file on disk to
a) remove a few lines
b) add a few more lines.
4) Click the Reload button.
Wrong `size` attribute on Firefox.
----------------------------------
Impact: Firefox
The advertised `Content-Length` HTTP header in the POST request is
a) *greater* than the actual body length. The backend web application
hangs on a `socket.recv` like function waiting for those missing
bytes.
b) *smaller* than the actual body length. The request is truncated
and futher processing is impossible.
The malformed request should have been detected and reported by the http
web application as requested by the HTTP/1.1 spec [1]:
> When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
Mitigating the issue is possible using nginx as reverse-proxy. The
connection is closed after one minute if data are missing.
Invalid `ERR_UPLOAD_FILE_CHANGED`
---------------------------------
Impact: Chrome on Windows
Chrome prevent sending the XHR due to a `ERR_UPLOAD_FILE_CHANGED` error,
this error should only happens when the underlying file content have
been changed the second before the request. On Windows, the error
is triggered as soon as the file have been changed, not considering the
modification time.
[1]: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html Section 4.4
opw-2252440
closesodoo/odoo#52276
X-original-commit: 30be09cdb7d5b80fb1e0221f58024586bd72ac61
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Similarly to server actions, searching and viewing the model on which a
scheduled action is defined is useful for administrators.
closesodoo/odoo#52239
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Issue
Step done with "CRM" since main kanban view can be
grouped by 'res.partner' model:
- Install "CRM" app
- Go to crm and group by "Customer".
- Add a Column.
Traceback is raised.
Cause
Wrong "default_type" in context ('opportunity' in this case)
when creating new kanban stage and grouped by "Customer".
Solution
On "default_get" for "res.partner", if "default_type" is in
context and not in 'type' selection choices field; then
remove it from context.
Cherry-pick of #47723 in 12.0
opw-2256905
closesodoo/odoo#52282
X-original-commit: e5796429c8adcbb929cb032cdfd2cbaba835b086
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
*: web_editor
Note: on color palette change, all the colors of the user are reset and
he is warned about it.
Part of https://github.com/odoo/odoo/pull/52224
task-2197038
*: web_editor, web
Also now allows to control the copyright section color.
This commit also allows to use color name alias when the user choose
one of the 5 main colors or a gray color for one component (e.g. if the
user picks 'o-color-1' as the color for its text in preset 4, then it
will no longer be linked to the current css color of 'o-color-1' but to
'o-color-1' directly; meaning that if that color changes in the future,
so will the text of preset 4).
Part of https://github.com/odoo/odoo/pull/52223
task-2197038
Before this commit, the company address was aligned to the left in a column.
closesodoo/odoo#51626
Taskid: 2198488
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently, In expense reports 'to pay' filter return data of state
'approved' and 'posted'. But the 'to pay' filter should only return
expense reports whose state is 'post'.
After this commit, the 'to pay' filter return only data of 'posted'
state and also removed some unused actions.
closes odoo/odoo#51638
Taskid: 2261481
Closes: #51638
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* web_editor
Now, if the opacity of the bg color for a bg classes is lower than x
(currently 0.3), the class will only control the bg and not the text
and other components anymore. This behavior is disabled for presets
though (otherwise the text color would be "undefined").
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
*: web, web_editor
Now, the user can edit each individual component of each color preset
thanks to the third tab of the left panel. The edition of the first
preset is the same as the others for the users but it is actually
also used for "no-preset" areas, meaning that they impact the whole
website by default (*without impacting the other presets*). The website
thus appears as areas using presets, preset 1 being the default (in the
future all areas will be customizable with a different preset). The only
difference between "using preset 1 explicitely" and "not using a preset"
will be that background color is transparent in no-preset, leaving the
body background appear. If the body background has no image, then there
is no difference at all as the background color of the body is set to be
the background color of the preset 1. In boxed mode, that color is used
for the "box" and the website body uses a different customizable color.
Note: before this commit, the "text" color edition was used to set the
main text color and one of the constrasting color for the color-yiq
function (the darkest if a dark color or the lightest if a light color).
That last part has been removed and automatic colors will now always
use $gray-900 and $white as contrasting colors, unless changed by the
theme explicitely. This needed to be removed as now the "text color"
edition has been moved in the "preset 1" config and should thus only
impact the "no-preset / preset 1" areas instead of all the presets.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
*: mass_mailing, website_blog, website_forum, website_hr_recruitment
Deprecate alpha, beta, gamma, delta and espilon color names and now use
a new color system: o-color-x, with x from 1 to 5.
This will allow to review the colors of all themes to have nice visuals
for the new color combinations classes, without breaking the current
uses of bg-alpha, alert-delta, etc in current websites of customers
(by keeping the old color and classes for compatibility).
This will also allow to uniformize all themes under the same conventions
to enforce BS color override:
- o-color-1 used as primary (as before, for alpha)
- o-color-2 used as secondary (as before, for beta)
Before, some themes were not following the 2 guidelines. The users
using those themes will simply have the possibility to choose o-color-1
and o-color-2 colors accordingly to restore their website without
breaking the new system features.
Another change is that those colors are defined through color palettes
and not theme color palettes. This will avoid them to generate automatic
bootstrap classes which we don't want (alert, btn) and generate the one
we want by ourself.
Note: for mass mailing, the colors and classes also have been renamed
but the system stays unchanged.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
Now, the colors used in a color combination are accessible and possible
to override through the BS $colors map, with a specific prefix
(o-cc for "color combination").
So, to access the 'headings' color of the color combination 3, use:
color('o-cc3-headings');
If you don't need to completely override a color combinations preset,
you can override what you want through a color palette:
$o-color-palettes: (
(
'text': red,
'o-cc4-btn-primary': 'alpha',
// ...
)
);
As our current system allows the user to customize colors of the color
palette (like for menu, default text, etc), this will allow to easily
give them the possibility to override combinations colors in a future
update.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
*: web, web_editor, website_blog, website_event
New o_cc${xxx} classes where ${xxx} is a number [1-5] to style snippets:
they come with a background color, a text color, headings colors, a
link color, primary button colors and secondary button colors which
will later be possible to customize by the user.
The classes are made so that they are working on two levels. So if a
column receives a color class and the snippet too, everything will work
fine. More than 2 levels are not supported and the editor is made so
those cases should not appear. See o_colored_level class.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
Correctly generate a text-muted color starting from an rgba value.
The 'scale-color' function will take in account the source color's
alpha, decreasing its value.
e.g.
```
$color: rgba(#fff, 0.7);
$muted: rgba($-yiq-color, 0.7);
-> rgba(#fff, 0.7) (same as source value)
$muted: scale-color($-yiq-color, $alpha: -30%);
-> rgba(#fff, 0.42) (correct)
```
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
Changing 'alpha' does not change the other colors which have been chosen
by the user. If only 'alpha' is chosen by the user, then the other
colors are still adapted accordinly (compatibility).
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
This reverts commit d3bd67fa12d85515fa6683f7b5d9ae114056bb62.
Even though there might be a usability issue, we need to have the
previous behavior because of the following case:
We have now a problem for the regex pattern, and it shows in the demo
data (lines `R:9772938 10/07 AX 9415116318 T:5 BRT: 100,00€ C/ croip`)
What we have now is
Name | debit | credit
-- | -- | --
Due amount | 0 | 100
Bank Fees | 0 | 96.67
But what we wanted was
Name | debit | credit
-- | -- | --
Due amount | 0 | 100
Bank Fees | 3.33 | 0
closesodoo/odoo#52195
X-original-commit: 35c31bb80b7a2cb8a855bbc05c66ca70ab71261e
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Purpose of the task is to remove the activity_exception widgets to
avoid redundancy. We have already added the activity on some list view
so activity expection widget on those list view is useless.
So in this commit, remove the activity_exception widget from
following tree view
- hr.expense.tree
- hr.expense.sheet.tree
- note.note.tree
- project.task.tree
- purchase.order.inherit.purchase.order.tree
- sale.order.tree
closes odoo/odoo#52109
Taskid: 2266720
Closes: #52109
Related: odoo/enterprise#10846
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Issue
- Install "Website" app
- Go to Website->Configuration->Redirect
- Click on Create
- Set "Action" to 308
- Set "Url to" to nothing or any url
with no leading '/'
The DB is broken.
Error in 'werkzeug' python library.
Cause
Missing leading slash in url or empty url.
Solution
Add a counstraint to check if url is valid (not empty and
with a leading slash).
opw-2266935
closesodoo/odoo#52189
X-original-commit: fe1e76638132197ef4804d1261fb5b9e23d44159
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When owner and/or packages are activated, a MO doesn't give the
possibility to set the proper owner/package of the reserved products.
We add the fields in the view, and set them as optional.
Important note: this will only work with the move lines created during
the reservation. If additional move lines are created manually, this
won't work. Indeed, it would be necessary to add both fields to
`raw_workorder_line_ids`, hence to `mrp.abstract.workorder.line`.
opw-2260450
closesodoo/odoo#52180
X-original-commit: 7f84ef7c8a292a5e95b26f7923923271b7b109b7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
*: web, web_editor
Disable the automatic generation of bootstrap color buttons and do it
ourself with a tweak: we introduce btn-fill-* (working as the normal
btn-* classes (in opposition to btn-outline-* classes). We then map
btn-* classes to either btn-fill-* or btn-outline-* classes depending
on the configuration (with a sass extend).
Part of https://github.com/odoo/odoo/pull/52220
task-2197038
closesodoo/odoo#52220
Related: odoo/design-themes#288
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now only suggest bootstrap classes for buttons: link/primary/secondary.
Also review the link dialog to show only the options which are
meaningful to the chosen type.
Note: it will still be possible to change from an old color to primary
or secondary).
Part of https://github.com/odoo/odoo/pull/52220
task-2197038
Also extend bootstrap to not use that style on specific elements like
btn, dropdown-items, etc.
Part of https://github.com/odoo/odoo/pull/52220
task-2197038
*: web_editor
Note: this work also prepare the code to be able to support different
font configs per font family.
Part of https://github.com/odoo/odoo/pull/52220
task-2197038
Future changes will require a different order of the code in that file.
This commit only reorganises the file to make future code review easier.
Part of https://github.com/odoo/odoo/pull/52211
Related to task-2197038
closesodoo/odoo#52211
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
