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>
Every tax should have at least one tax line.
closesodoo/odoo#86128
X-original-commit: 6d206e74dca14cf1f783906e6f30efa6664b7120
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
The goal is to add a digital stamp on the Invoice PDF
stating the name of its related Vendor Bill.
Auditors may request printed copies of all (original) Invoices
as well as the possibility to relate each document
to a posted entry (Vendor Bill).
task-2755372
closesodoo/odoo#86127
X-original-commit: f0ea39791c70cc63fe39665514e5344a56ed5b71
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>
Expected Behaviour
When creating a contact from a lead with an unactive language, Odoo should
replace this language with the parent's language or the DB language.
Observed Behaviour
Since saas-15.1, when you create a contact from a lead email adress,
the contact is created with the lead's language, even if it's not active,
which give an error.
Reproducibility
This bug can be reproduced following these steps:
1. Set an uninstalled language on a lead (two choices):
a. Select an uninstalled language on a lead (this is what happens with
the trial creation, and how to reproduce it via the interface)
- install 8 languages in order to activate the "Search More..." link in
the Language select field of a lead
- on a lead which doesn't have a Customer yet, in the Language, "Search
More...", filter with Active = False, and select an uninstalled language
b. Install a language, select it on a lead with no Customer, and uninstall
the language
2. On the lead, in its chatter, open the Send Message and check the checkbox
next to its email => it should open a popup
3. Validate the popup => there is an exception in saas-15.X, and not in 15.0.
Related Issues/PR
- opw-2745841
closesodoo/odoo#85992
X-original-commit: c9b6ec91a87a4ad007287d978adc34332a97f8da
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The purpose of the PR is, User/validation errors are sometimes not
correct in English and/or quite obscure and don't help the user
understand/solve the issue. so some copywriting should help make
the experience better.
task-2557805
closesodoo/odoo#80107
Related: odoo/enterprise#22402
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
During 28f910f some `oi` utility-classes that were supposed to be
removed have been forgotten, causing `fa` icons to don't be rendered
properly.
This commit will remove the unnecessary classes solving the render
issues.
task-2790138
closesodoo/odoo#86102
Related: odoo/enterprise#25128
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The website_forum_share_templates does not exclusively contain templates
to the forum share widget since the addition of the toolbar template.
Renaming the file to public_templates arguably makes more sense.
task-2749467
closesodoo/odoo#85998
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
An extra xml dependency was inadvertently added in the ForumCreateDialog in
commit [1] by inheriting the web_editor.toolbar template, since the file where
it is inherited is an xml dependency of the ForumCreateDialog widget. While the
dependency is correctly loaded in the public widget it is not in the creation
dialog widget, resulting in a crash.
Furthermore, the ForumCreateDialog widget does not actually need this template
and neither does the public widget need the other templates already present
in the same file at the time of the mentioned commit. Moving the extended
toolbar template to the website_forum_share_templates file, allows for removing
of the unnecessary dependencies. This includes the missing dependency of the
ForumCreateDialog, preventing the crash.
[1]: 740168ce8d
task-2749467
X-original-commit: 4ad966de67278c2081c1896c354b9b1782cf6dc1
Part-of: odoo/odoo#85998
This commit helps reducing the noise of the model definition PR. Indeed,
the partner_id field on the mail.follower model was mocked as an integer
field. The /mail/thread/data route returns an integer. But the search
read method returns an array for many2one fields [id, display_name]. Thus,
using the real server field will result in an incorrect behavior.
task-2767820
closesodoo/odoo#86096
Related: odoo/enterprise#25125
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
To properly register account_edi_proxy_client.user when saving the res
config settings page, the radio buttons needed to be modified, and the
'register' button was adapted to be a checkbox instead.
Registering multiple demo proxy clients lead to an error, as it is
asserted that id_client should be unique, and the demo client has
'id_client': 'demo'.
To fix this, the id of a demo client is 'demo' + the company id.
Searching for demo clients is adapted to search on the first four
characters.
closesodoo/odoo#85794
X-original-commit: 54e54466f0858d4b19fa8f61ff2b927e00f8f5a8
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Issue introduced with 030b1ba
Before this commit:
The hotkey overlays were not toggleable more than once in a row.
After this commit:
They can be.
closesodoo/odoo#86089
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In sign many NameAndSignature widgets are opened and closed since it is
expected that documents have multiple initial/signature fields. Everytime
the widget is opened, an rpc call to get_fonts is done, even if the request
has already been done before. This commit prevents this rpc call if the fonts
are already loaded.
task-2735814
closesodoo/odoo#83208
Related: odoo/enterprise#23653
Signed-off-by: Arnaud Joset <arj@odoo.com>
Steps to reproduce the bug:
- Create a batch transfer with moves from the same warehouse to several locations, e.g:
- Product A from `WH/stock` → `customer/stock1`
- Product B from `WH/stock` → `customer/stock2`
- Try to print the batch transfers
Problem:
Traceback is triggered because we do a loop only on location_from
Solution:
- We need to loop over location_from and location destination
- Remove useless use of mapped
opw-2768518
closesodoo/odoo#86082
X-original-commit: 6721d1dfe53fb8d301188f2fb4c21baa70c27b92
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Prior to this commit, the url build using the concatenation between the
base url and the webhook url path produced a wrong url with two
consecutive slash.
This commit prevent from building a wrong url, using the url_join api
method.
In the commit d3f4619b , the base url was fixed but there was a
remaining url-join error.
Original commit: 4296b2653
closesodoo/odoo#86073
X-original-commit: 8b4d7fa3ae9d470bd12d5c09d6270a637311c0c4
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
For payment_buckaroo and payment_sips (at least) running with a
non-standard port is an issue to the `test_redirect_form_value` tests:
while the form and test will use respectively the base_url and the
configuration port, both check a response signature which is
predicated upon a base url of `http://127.0.0.1:8069`.
This means the test does not pass when run with a different port, and
may not pass if the database was installed with a different port
either (because this may have caused the `web.base_url` to be set to
the installation port).
The other payment modules don't seem to have such signature
verification and thus apparently don't mind running with non-default
port.
Update in 15.2: `test_webhook_notification_confirms_transaction` also
broke but differently, because the payment utils would fetch (and use)
the `web.base.url` they get confused if a db is installed using one
port then the tests are run using an other (or something along those
lines), despite `HttpCase` trying to set the `web.base.url` (could be
an ordering thing).
Anyway a working solution seems to be to *remove* the bespoke code
from `PaymentTestUtils` and fix `HttpCase.base_url()` so it uses the
right port (apparently that'd never been fixed). This does require
adapting the patch being forward-ported as `base_url` is now a
callable, not an attribute.
Also re-remove the attractive nuisance of the odoo.tests.common.PORT
constant which does not work: it is evaluated before the configuration
has been loaded and is thus always set to the default (8069).
closesodoo/odoo#86068
X-original-commit: c28c99f7399da91e1a6176d6f97d4fc947013cae
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Every tax should have a tax repartition line.
closesodoo/odoo#86048
X-original-commit: 2b39bfd6cf0370a1f76a5a150bbf6a92c2fdf555
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
This will be useful to allow concrete views to attach event listeners to
their root element among other things.
closesodoo/odoo#85891
Related: odoo/enterprise#25030
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Users who select Stripe as their payment acquirer will now have the
possibility to capture manually the amount later (e.g. when delivering
the product).
task-2278434
closesodoo/odoo#69598
Related: odoo/upgrade#3290
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
It's currently confusing: the default value is already 'groups', but the create
method is actually giving another default.
task-2749643
closesodoo/odoo#86075
X-original-commit: 31dfc797bc0fb163b6e32d3fe2195791b674f00c
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since [1] only floating fixed headers were included in the calculation
of the `dom.scrollTo()`'s offset.
Because of this when a snippet was dropped on the top of a page, the
header being shown but non-floating was not used in the offset
calculation, which made the automatic scroll operation hide the header
partially for headers taller than the requested 50px offset from the top
of the display.
After this commit, any shown header is included in that calculation -
even non floating ones.
Steps to reproduce:
- drop snippets into the page until it has to scroll
- drop a snippet right below the header
=> header was partially hidden upon drop by the automatic scolling
[1]: https://github.com/odoo/odoo/commit/ee47bd9ce0da526ea5b3387a354ab8fbd06cc55f
task-2765820
closesodoo/odoo#86038
X-original-commit: f3e51a7beb4b0d4ccb6a883d2c53bd303e94a200
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Just have some numbers before working on composer onchange removal and see
its impact.
Task-2789182 (Account: Invoice send performance test)
Prepares Task-2088884 (Mail: Composer onchange removal)
closesodoo/odoo#85902
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The plain-text mailing template had no top padding, which made it
awkward to edit and tended to make users manually add space at the top
of the mailing with paragraph breaks. This adds the same padding to the
mailing as is applied to the editor in the Note module.
Note: since the mailing is plain-text, that padding shouldn't and isn't
saved in the mail to send, resulting in a visible difference between the
Mail Body and Mail Debug tabs. This is normal.
task-2760178
closesodoo/odoo#86043
X-original-commit: 82d40ab312fc506c6e248ef3c01cccc99ce6ff73
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Sadegh Ismael Nattaj