Purpose
=======
Add globe button next to language for leads and opportunities if the
database is in multi language mode and user has enough access rights.
User is also unable to edit language from view
PR: odoo/odoo/pull/78287
Task-2662548
Part-of: odoo/odoo#78287
THe price shown on the order line was not taking into account the
quantities ordered.
closesodoo/odoo#85872
Taskid: 2678064
X-original-commit: f9243560e667c319a1710ded98f157634b0fa2dd
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current behavior:
When you use a workcenter with start and stop time in a BoM the start/stop time is applied for each quantity in the BoM report and workorder. For example if you have 3 quantities the start/stop time
will be applied 3 times.
Steps to reproduce:
- Create a product to manufacture (With atleast 1 operation)
- Create a workcenter that has positive Start/Stop time values
- Start and stop time are multiplied by the quantity in the BoM report
opw-2779381
closesodoo/odoo#86321
X-original-commit: 3bb32903f90fa86eb28b4551b07a5817f8e9f528
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This commit aims to allow assigning tags to the taxes
created by the OSS feature by providing the xml_id of their
report.line in the eu_tag_map.py file.
Before this commit:
In l10n_be, the taxes created by OSS (l10n_eu_services) didn't set
the tag +47 on invoice_repartition_lines nor +49 on
refund_repartition_lines.
This make the VAT report for Belgium wrong.
After this commit:
Taxes created by OSS for a company using the belgian CoA will get
their tags set properly and thus will the taxes impact the
belgian tax report correctly.
task: 2770182
ticket: 2768622
Community-PR: https://github.com/odoo/odoo/pull/85607
Design choices:
This fix is currently solving the issue for l10n_be but we have
no doubt that it will be raised for other EU countries too.
In order to provide the tags, we decided to be consistent with
what as been done regarding the tax mapping. Thus we decided to
create and maintain a simple mapping file and to test it.
several other methods were explored:
- create a global variable and update it from all localization
modules. This method would work but is ugly and error prone.
- create a templating method and override it from localization
modules.
The problem is where to set the root of the template method?
The naïve solution would be to create a bridge module between
l10n_eu_services and l10n_be but that would lead to an explosion
in the number of bridge modules which we don't want.
In order to keep things simple and generic, we could put the
template method directly into the account module. But it is kind
of ugly because account shouldn't know anything about the oss
feature and it would encourage such a leaky design to happen
again in the future.
closesodoo/odoo#86314
X-original-commit: 7dcc2ae4665d2d7b577ed10160691775b86a848f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
Before, when sending an invoice for the first time, it would give
a "cannot find savepoint" traceback upon wanting to release it.
We avoid that error by putting less code in the with statement,
so the savepoint gets released a lot earlier while the record
remains locked for the rest of the transaction.
We also put a nice error message if the user can not send at the
moment because another process is already sending. (might happen
more often in v15)
We also updated the translation .pot as we added a new message
and some messages were missing anyways in the .pot, so we added
those as well.
closesodoo/odoo#86317
X-original-commit: a135ef6c78a5ddd1eed36bbb91ee01d82c18e592
Signed-off-by: William André (wan) <wan@odoo.com>
The purpose of this commit is to include SMS templates. Templates allow people to
customize the content of sent SMS. When the project/task stage changes, the user will
be notified and there will be a track in the chatter.
- add this field on the right of the 'email template' one in list view.
optional and hidden by default.
- add it below the 'name' quick search in the search view.
task-2683575
closesodoo/odoo#81311
Related: odoo/enterprise#22853
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The issue is simply creating a related stored many2many field, which is
pretty easy to do with Studio. When creating the field, Odoo crashes
with a traceback caused by ondelete being None on the field.
The source of the bug is the fact that the attribute field.ondelete is
set to a sensible default ('cascade') on non-related fields only. The
fix consists in setting the default value on the attribute itself, so
that the setup of the field never falls on a case where field.ondelete
is unset.
closesodoo/odoo#86303
X-original-commit: d0e0d80806a1b63ac986e9bcbaf88f9fc5243319
Signed-off-by: Raphael Collet <rco@odoo.com>
Steps :
Create a recurrent task.
Delete it.
Run the cron "Create Recurring Tasks".
Issue :
IndexError: tuple index out of range.
Cause :
The cron calls a method which takes the last task of the recurrence
as a model. As there is no such task, an python error is thrown.
Fix :
Do not display the "Continue Recurrence" button when deleting the last
task of it.
opw-2743788
closesodoo/odoo#86309
X-original-commit: 9cfe0042dd6846cf8b52aebeb9dd6e7432b32322
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, when making an import on the project. task and trying to enable the
'recurring_task' to True, the field is updated but a recurrence record is not
created.
Steps:
1. Create an import file of a new task record
2. Add 'recurring_task' field set to true
Technical Description:
The default value is not set when the file is imported. Such as repeat_interval,
repeat_unit etc. So we have called the default_get method.
task-2733539
closesodoo/odoo#86283
X-original-commit: e24ae464caa068fa0a9b87fd7573528973eb25a4
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The smartbutton for the number of hours in the attendance smart button
on employees and user did not use the right widget and could display
invalid data like '1.8 hours last month'.
TaskId-
closesodoo/odoo#86280
X-original-commit: 230f9185a7de214a0f3d445617bb9b0496d6fc49
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- On bank journal, set at least two manual
outbound_payment_method_line_ids
- Set a vendor X with manual property_payment_method_id
- Create a Vendor Bill with vendor X, confirm it, and register payment
OR
- Create a payment with outbound method and select vendor X
Issue:
Got a traceback
The reason is we expected one value instead of several.
With this commit, we take the manual payment method with the
highest priority based on its sequence number.
opw-2743110
closesodoo/odoo#86270
X-original-commit: 6235466e70cefd5d948ce06dd39fb04d88387a43
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose
=======
On product list we can see that kits are listed with quantity on hand
equals to the lesser quantity of the kit's components.
When applying the filter **Quantity on hand greater than 0**, the kit
disappears from the list.
The issue is that we compute product quantity from stock.quant, for kits
we don't create a quant beacause it's not a physical product.
Specification
=============
To solve the issue, we extend the method **_search_qty_available_new** from
**stock.product** in **mrp.product**, where we fetch all kits and add the id
of the products that verify the given condition.
opw-2717594
closesodoo/odoo#86262
X-original-commit: 9db235a0d8cb1f7a371a1dec8a441329de5d5eb8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Finetuning of #85774Fixes#86174closesodoo/odoo#86260
X-original-commit: 6fff9ac8b4f86469c11e404442f928c2b6616e2b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
see https://github.com/odoo/odoo/pull/77771https://github.com/odoo/enterprise/pull/23738
These PR are updating a template and adding a new dependency in
account_report. This has the side effect of making account report
raise a traceback when invoicing has not been updated prior to that.
With this change, we will bump the version of account and use it to
make sure that it has been updated as we would expect prior to updating
account_reports. If not, we will raise a user error with an explicit
message asking the user to update invoicing.
closesodoo/odoo#86217
X-original-commit: 0ec9e16cae0cdaa99cfb181b40658e15e34e0b14
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, when the user hit the key enter, in the media
dialog, in the icon tab, in the input, the page was reloaded instead
of searching for the icon.
Task-2733154
closesodoo/odoo#86218
X-original-commit: 7b3bead23f9bc38003afd4253f4ff4556b550598
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Previously, the tooling for web ran on all branches, this can cause
problems because it will automatically lint all files that have been
changed on commit, which can cause a lot of noise in the diff which is
undesirable in stable branches, as it makes forward ports more
difficult, among other things.
This commit adds a condition in the tooling so that it only runs on
branches whose name starts with master to fix this issue.
closesodoo/odoo#86200
X-original-commit: 5962b63f4ad1cfeccc0a80de2307300b50492668
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since [1] the class `o_we_force_no_transition` was not removed when
selecting a snippet when the background color was a gradient. (It was
however removed when selecting a background color.)
After this commit the class is removed in that situation just like for
any other `data-select-style` attribute.
[1]: https://github.com/odoo/odoo/commit/a48a30f954afcb6ff3a59c4f32b05fd0c2cfcd2b
task-2633169
closesodoo/odoo#86126
X-original-commit: ed530aef3c6d99712db055099b5f06a31e91d9cf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
A server action sometimes returns an action with a help key.
That help was not marked up, leading to an incorrect display of that help.
closesodoo/odoo#86170
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Persian language native name misspelled as "فارس" instead of "فارسی"
closesodoo/odoo#86225
X-original-commit: 073affad1595ca011f8af95be759bfc656cffe7e
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The aim of this commit is to correct the compute_all calculation
when it is dealing with an article with 0.00 price and having a fixed
tax included in it.
In this situation, this means the tax is directly taken as an expense
by the company that offers it to its client.
This also solves the situation in which we have a 100% discount because
discount is applied before calling `compute_all` by changing the
unit_price.
Before this commit:
Creating an invoice with a line having a price at 0 or a 100% discount
and a fixed tax price_include resulted in a really weird behavior: the
company had to reimburse the customer for the amount of the tax.
(what a lucky customer :D )
After this commit:
Customer is sad, he only gets the product for free.
The base is calculated as negative, resulting in a debit amount on the base
income line.
The tax is then counterbalance by it.
The form is displaying a negative untaxed amount, a positive tax and the
total is 0.
closesodoo/odoo#86223
Ticket: 2660808, 2637512
Community-pr: https://github.com/odoo/odoo/pull/85747
X-original-commit: 727d19cb4e012e9a24d94640987ac5ea6f452a2e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
*: hr, hr_holidays, im_livechat, mail, snailmail, test_mail, website_livechat,
website_slides.
This commit will remove the need to duplicate models definition for
test purposes. Indeed, for now, we need to mock the model definitions
on the client side. Those models definitions are often very different
from the ones found on the server.
This approach will allow us :
- to ease model definitions during tests
- to get closer from the real models
task-2767820
closesodoo/odoo#84828
Related: odoo/enterprise#24486
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prior to this commit, profitability report views aren't accessible
anymore for a user since no more actions related to this report exists.
This commit removes those unused views in order to have a clean code
base.
Pr: #77024
Related: odoo/upgrade#3150
Related: odoo/enterprise#23264
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit removes the `user_ids` fields in the project sharing views
because this field is replaced by the `portal_user_names` fields to
correctly display all the users assigned to a task.
This commit also removes some elements defined in the project sharing
views and they are unused anymore since they are invisible.
Part-of: odoo/odoo#77024
`account.analytic.line` has been set as translatable in saas-15.1. In hindsight,
we can say it was clearly a bad idea as it introduced complexity and confusion.
This is why we are reverting it.
closesodoo/odoo#86203
X-original-commit: 0e0d9e76c6735a688707d51b54f8e978c168a1d9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the /payment/pay page would not filter out acquirers
configured to allow tokenization when it was although required for the
payment. For example, for sales order with a subscription product (which
requires tokenization), acquirers that don't allow tokenization would be
shown to the customer if they pay from the /payment/pay page, but not if
they pay from the portal view of the SO.
This commit makes sure the sales order id is correctly propagated to the
Subscription app which then flags the payment as requiring tokenization.
closesodoo/odoo#86202
X-original-commit: 9ab7b2447f2ece46f1a25335ab76f06323f03d22
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
3c71f66bb541fcf31f31e75b60f7825d26109bc4 fixed the fact sometimes the answer of another user than the one we wanted could be loaded when restarting a survey. With this fix, we introduced a check on the partner having created the answer the user was trying to access. It became impossible for a user to access an answer which wasn't his.
While correct in the case we were fixing, this introduced an issue with the /survey/print/ route, which allows any user with the right tokens to visualize the answers of another. We fix this by making sure we don't check the partner when accessing this route, to restore its former behavior.
closesodoo/odoo#86189
X-original-commit: cffc732e58c14541abcf06bb0d58add224396b7c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
Steps to reproduce the bug:
- Let's define a sale python tax T where Python Code = product.list_price
- Let's consider a product template PT
- Try to set T on PT
Bug:
A traceback was raised because variable product was not defined when evaluting
the python code in function compute_all (defined in module account_tax_python)
opw:2787007
closesodoo/odoo#86145
X-original-commit: 718048e7d8e875b4a3be183acabc0e6ab67836b6
Signed-off-by: William André (wan) <wan@odoo.com>
How to reproduce the bug ?
- install the accounting, contacts and purchase apps
- create several companies and enable the checkboxes of all
these companies
- create a new contact and add a bank account for each company
- switch to a company different than the first one
- create a request for quotations in the purchase apps and
confirm it
- in the accounting app, create a new vendor bill and use the
auto-complete field to select the RFQ created earlier.
The bug:
When you try to create a vendor bill from a request for quotations,
the recipient bank is wrongly chosen. Because of that, there will be
2 issues. The first one is when you want to create the bill from the
RFQ: you will get an error and the invoice won't be created. The second
one is when you create an invoice then use the auto-complete field. In
this case, there won't be any error but the recipient bank will
be wrong.
opw-2731264
closesodoo/odoo#86078
X-original-commit: 074fee2e19547f4145ae0aa93d68741ab4aa9bae
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Re-integrate code from 37681e9d2e24663691b4be022f34c29c7126d9f6
lost with f11fcf6bb4
allowing different quantities to be recorded on work orders
and generate back orders with correct quantities on back work orders
(cancelled if no remaining quantity).
closesodoo/odoo#84502
Task: 2751230
Related: odoo/enterprise#24624
Signed-off-by: Steve Van Essche <svs@odoo.com>
Assets bundle are wrongly regenerated on the following circumstance.
The use of multiples tag `t-call-assets` in some xml template(s) with:
- at least one `t-call-assets` with `t-js` or `t-css` to false
- at least one `t-call-assets` without `t-js` nor `t-css`
In mass_mailing, the buggy regeneration of assets happens at a critical moment
and break the url of a previously generated asset. That url was however saved
in a javascript cache and therefore the bundle is inaccessible. No css style is
therefore applied to the page.
Note 1: the bug for the previous specific case in mass_mailing only
appears if within all the files defined for the bundle
`web_editor.wysiwyg_assets`, the last modified file (mtime) was of
type javascript. No visible bug would appear if the last modified file
was of type stylesheet (css, scss, ...). However, the asset would be
regenerated at a time where the cache should be used (invisible for the user).
Note 2: in order to reproduce the bug systematically without this commit,
it is necessary to disable the browser cache. Otherwise, if the
browser has the broken url in cache, no http request will be made and the bug
will not appears.
The bundles are wrongly regenerated because of how the url is
generated. Part of the url is generated using the "version" of the
bundle. The version is defined using a checksum. The checksum uses
information about the *last modified* file of the bundle. And this is
where bug arises.
If the bundle was called with `t-js="false"` the list of file didn't
include js files.
- The version for the `css` bundle will be A
If the bundle was called with `t-css="false"` the list of file didn't
include css files.
- The version for the `js` bundle will be B
If the bundle was called without `t-js` nor `t-css` the list includes
all js and css files.
- The version for the `js` bundle **and** the `css` bundle will be A
if the last modified file type is javascript or B if it is a stylesheet.
This commit change the behavior to always consider all the files last
modification within bundles in order to derive the version.
Thus:
If the bundle was called with `t-js="false"` the list of file didn't
include js files.
- The version for the `css` bundle will be A
If the bundle was called with `t-css="false"` the list of file didn't
include css files.
- The version for the `js` bundle will be A
If the bundle was called without `t-js` nor `t-css` the list of file
includes.
- The version for the `js` bundle **and** the `css` bundle will be A.
Example:
assetsA has two files:
```
file1.css
file2.js
```
file1.css was last modified at time A
file2.js was last modified at time B
bundle A
```xml
<template name="template_a">
<t t-call-assets="assetsA" t-js="false"/>
</template>
<template name="template_b">
<t t-call-assets="assetsA" t-css="false"/>
</template>
<template name="template_c">
<t t-call-assets="assetsA"/>
</template>
```
In a javascript file:
```js
const ajax = require('web.ajax');
await ajax.loadAsset({assetLibs: ['template_a']});
await ajax.loadAsset({assetLibs: ['template_b']});
await ajax.loadAsset({assetLibs: ['template_c']});
await ajax.loadAsset({assetLibs: ['template_a']});
```
Whenever loading a assets of a template, the urls for the css and javascript
files are saved into a cache until the next browser reload.
In this example, without this commit:
- the first `ajax.loadAsset` `template_a` generate a css asset with version X
-> a css file is generated and the url of the css file is
`/web/assets/version_X...min.css` and is saved in the javascript
cache for `template_a`
- the `ajax.loadAsset` `template_b` generate a js asset with version Y
-> a js file is generated and the url of the js file is
`/web/assets/version_Y...js`
- the `ajax.loadAsset` `template_c` generate a css **and** js asset
with version Y if time A (a css file) is bigger than time B (a js
file):
-> a css file is generated and the url of the css file is
`/web/assets/version_X...min.css` and is saved in the
javascript cache for `template_c`
-> a js file is generated and the url of the js file is
`/web/assets/version_X...js`
if time B (a js file) is bigger than time a (a css file)
-> a css file is generated and the url of the css file
is`/web/assets/version_Y...min.css` and is saved in the
javascript cache for `template_c`
-> a js file is generated and the url of the css file is
`/web/assets/version_Y...js`
--> because the css file is re-generated (the version changed from
X to Y), the url in the javascript cache is no longer valid.
- the last `ajax.loadAsset` `template_a` use the url in its cache and
either the css url or the js url would no longer will be available
and a http error will trigger if the code tries to access it.
Task-2778413
closesodoo/odoo#86155
X-original-commit: 2267cfc947eff9fc4f00468610a82c8fbbca36ad
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when:
- client A close it's laptop temporarily, client B
- client B save another content
- client A re-open it's laptop
then, client A still have the outdated record version.
Now, if client A reconnect and the record has been modified, the
editor gets reset with the updated record.
Task-2745104
closesodoo/odoo#86149
X-original-commit: 1070d37a6c02c8a873336f4533d1e319a8762405
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Add a check to ensure that the repartition lines have at least one tax line.
Reason: the compute_all fonction skips the taxes with no tax lines
because it only loops over the tax repartition lines to fill taxes_vals
closesodoo/odoo#85943
X-original-commit: 783d604fd66f813b66b0bac769f22c1dc0ed761f
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
In `account.move` `_stock_account_prepare_anglo_saxon_in_lines_vals`,
the `partner_id` is set two times, following those PR:
- odoo/odoo#75038
- odoo/odoo#84468closesodoo/odoo#86154
X-original-commit: 3db2db30a22b0da968c1c739d53dec40a4cabed8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Every tax should have at least one tax line.
closesodoo/odoo#86158
X-original-commit: 0d1bb4718de1c797798bf52d8730b6ebce97793a
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Steps :
Install project and employee.
Create 3 company and an employee for you user in 2 of them.
Switch to the one without employee.
Create a new project and task.
Register a timesheet.
Issue :
The timesheet has no employee.
Fix :
Display start button and set an employee on the ts
only if user has an employee in the company
or has only one employee for all companies.
opw-2745733
closesodoo/odoo#86135
X-original-commit: b439485bae49cfbef98ca4e1618c3b295d548109
Related: odoo/enterprise#25145
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Expected Behaviour
When a user goes to his own profile, he has two ways to change his password :
1. through the 'Account security' tab
2. through the 'Actions' > 'Change password' menu in list/form view
Both option should let the user change its password, or one of the two should
not be present
Observed behaviour
While the first one works as expected, the second option gives an error as
the user doesn't have the admin rights
Reproducibility
This bug can be reproduced following these steps:
0. Make sure to have the "Employees" app installed
1. Connect as an employee (e.g. demo/demo on runbot)
2. Click on your name at the top right, go to 'My Profile'
3. Click 'Action' then 'Change password'
Problem Root Cause
There is an override of field_view_get for the res.users model in the hr
module which elevates the user with sudo so that the user may modify their
own user in some capacity. The problem is that by elevating the ACLs of the
user, fields_view_get will also return actions that are not normally
available to the user (e.g. deletion of user profile)
Related Issues/PR
- opw-2735671
closesodoo/odoo#86116
X-original-commit: 6487a9ea7d25d14a86a7476b4b512f3681da7405
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
In discuss, the group DM default name does not contain any guest names in it.
After this commit:
Group DM default name will also take guest names along with other user names.
Task-2664859
closesodoo/odoo#86130
X-original-commit: 41f4c5741097b09c372406bbbd5364314bff6d1b
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Fabio Barbero