Purpose
=======
This is the optimal way to add a user on a group, to avoid calling the
contraint method _check_one_user_type on all the users from the group
closesodoo/odoo#87998
Related: odoo/enterprise#25908
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the ProductDiscountWidget (sale.product_discount) worked by overriding the reset method.
The main drawback is that the reset method is called whanever a field on the line is changed.
This commit rely on _onFieldChanged that allows to target single change. A small mixin is created to allow working with different kind of fields of the SOL.
taskid: 2568007
Before this commit, the sale module could not be used to manage subscriptions in an override.
This commit adapts the sale module to https://github.com/odoo/enterprise/pull/21825
taskid: 2568007
Currently, when modifying an invoice line and setting taxes
(price included) for 100%, the price_unit field will
be displayed as 0.
This is incorrect and is being fixed here.
opw-2793284
closesodoo/odoo#88180
X-original-commit: 674eaa3bc10210d34a02145529516da1fa1c1b66
Signed-off-by: Laurent Smet <las@odoo.com>
How to reproduce:
1- Create Product Category "PC" AVCO|FIFO Automated.
2- Create Storable Product "P" with product category PC and unit cost to 1.
3- Create SO with 10 units of P.
4- Create PO with 10 units of P and unit cost of 2.
Delivery of the SO should now have 2 IV layers, with one being "Revaluation of XXX (negative inventory)"
Global IV of P should be 0 qty, 0 value.
5- Return the delivery order of SO.
6- Open valuation of the return
Error: The value is 0, should be 20
In `_get_price_unit`, `price_unit` is taken on the last svl of the origin_returned_move_id, in our case it's the revaluation layer.
`_get_price_unit` now take all svls of origin_returned_move_id into account.
OPW-2784033
closesodoo/odoo#88177
X-original-commit: bfd1a06b054dcc115f7fb0937db98812f4a6d5dc
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: DavidFesquet <dafr@odoo.com>
Unnecessary call to _create_check_sequence because is called in create method and create is called in supper().copy()
TT35608
closesodoo/odoo#88159
X-original-commit: 2f83737b8eb4f2b378cf4d6a6348d9ba15200561
Signed-off-by: Florian Gilbert <flg@odoo.com>
This fix prevents the `/Annot` key from a PDF PageObject
to cause errors during its handling by PyPDF2.
opw-2811793
closesodoo/odoo#88182
X-original-commit: 1c0fc5b20efb9e5829447f97480d0813c6c9e367
Signed-off-by: William André (wan) <wan@odoo.com>
Manual forward port, commit was lost from 15.2 to master. Either it
seemed not needed after the httpocalypse refactoring, or was simply
lost during the rebase.
-----
We can remove an useless SQL Query for public user on every single page
serve, if we directly set the website's company_id in the available
company_ids of the public user.
Indeed, the public user from a website always have the same company_id
as the website.
We can then do that directly and bypass the next line which will
always be true in the case of the public user, making a read for
nothing.
task-2774979
closes#85419
X-original-commit: c95ab6f
[1]: https://github.com/odoo/odoo/commit/728ade674cb12c64718efda56b0d5d542e319cbaclosesodoo/odoo#87856
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: test_website, website_blog (test perfs)
An error regarding tests was not catch during httpocalypse [1] review.
The test query counts were lowered in website by 2 everywhere, but it
shouldn't have as there were no SQL perf improvement from this
refactoring regarding website.
The query count actually decreased because the test-only SQL Savepoints
got divided by 2, probably thanks to a low level test improvement in
the PR.
But outside of tests, there were no SQL Query gained.
This should have been reflected in the `EXTRA_REQUEST` variable
instead.
Before:
Savepoint > Rollback > Savepoint > [Actual SQL Queries] > Rollback
After:
Savepoint > [Actual SQL Queries] > Rollback
It is important to fix it because:
1. (Minor) There is a de-sync between the query count in the test and
the actual query count (in the logs outside of tests), making it
hard to figure.
2. (Major) Some controller got then wrongly lowered to 0 query counts
instead of 2. An incoming PR in master would then make those tests
expects negative query counts, which doesn't make any sense.
[1]: https://github.com/odoo/odoo/pull/78857
Note that the exact commit can't be found by bisect as those don't work
on their own, DB can't be started due to circular import.
Part-of: odoo/odoo#87856
Step to reproduce:
- install sale, accounting and l10n_de
- activate proforma in sale settings
- set the template to external_layout_din5008 in the settings (use developer mod)
- create sales order or quotation
- print it as a proforma
Current behavior:
- the proforma is missing from the title in the document
Behaviour after PR:
- the proforma is in the document title
The l10n_de_sale module was missing the case scenario of a proforma sales report and the sale module only
gives the information of a proforma report in the xml context. Then we add the case scenario and propagate
the proforma info from the sale module also in the python context using the proforma variable.
opw-2796603
closesodoo/odoo#88153
X-original-commit: 14e0f84abeba8453930522047df3610940d6aa9a
Signed-off-by: William André (wan) <wan@odoo.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
Enable discounts
Have a price included tax 10%
Have a product with sales price 100$
Make a SO adding the product, the price incl. tax and a 1% discount
Open the portal page of the quotation
In the left recap sidebar the price before discount is reported to be
100.10 while it should be 100.0
opw-2759804
closesodoo/odoo#87418
X-original-commit: db6994c2ac991822014d168022c854ba75f3095f
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Step to reproduce (Traceback):
- Be in multi-company
- Create a time off type with duration in hour and no company_id
- Create an instance of this type on company A with a user linked
to company A (need access to both)
- Switch to company B
Current Behaviour:
- Traceback
- Cannot fetch user's calendar if content of company A is not checked
for convertion from Days to Hour
Behaviour after PR:
- We only fetch if the user related to the leave is in allowed_companies
-> only fetch if the user data is available
- This is also true if duration is in Days/Half-Days (GMF Approved)
opw-2749258
closesodoo/odoo#88104
X-original-commit: cb5942e5461ec0fc1fa54cd249de23e4f28f8692
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit applies the correct primary colors to maintain consistency
with the overall design.
task-2817682
closesodoo/odoo#88088
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
``get`` default is a dict that gets evaluated to be sent as parameter,
causing an unnecessary read on the component's computed fields.
The read should only happen only if we don't have a value in ``res``.
closesodoo/odoo#88050
X-original-commit: 4d16869e5c0a627dfe32ad1c8f54e83373dc3c8b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Before this commit:
For guests and portal users, a separator(differentiates channel name and
description) in the thread view topbar is displayed even if there is no description.
And when portal users are trying to write/edit channel description at that time
access error is generated.
After this commit:
A separator will only be displayed when there is a description and portal users
will not be able to write/edit channel description as they don't have rights.
Task-2664843
closesodoo/odoo#87999
X-original-commit: 84604910af931131fd10ad37787a803c8905d55c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* Previously, when reconciling journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.
==== RATIONALE ====
This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:
Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)
..leads to a partial of 120 EUR and min(80, 60) = 60 USD
After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.
2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.
In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.
In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.
==== REFERENCES ====
Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.
github issue: https://github.com/odoo/odoo/issues/37469closesodoo/odoo#84201
Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
add get warehouse address method
needed in Indian EDI to pass value of dispatched address
improve demo data and bypass one GST number from validation because that GST number use to test EDI
Add Non GST Supplies and State CESS tax report line
Non-GST Supplies and State CESS is required to get related value from the invoice for send EDI
Part-of: odoo/odoo#79995
This follows up e045e76e35.
Change the heuristics for ordering columns, as padding is not determined
by column size, but by column alignment inside a row. Because in Odoo a
row always starts with a column of size 4, the following columns should
be the ones aligned on 4 bytes, then the ones aligned on 1 byte, then
the ones aligned on 8 bytes.
The analysis in the commit message of e045e76e was not correct, as it
did not take into account the fact that rows themselves are aligned on 8
bytes. So we have: before each row used 40 bytes (+24b header)
attname | typname | typlen
-------------+-----------+--------
id | int4 | 4
create_uid | int4 | 4
create_date | timestamp | 8
write_uid | int4 | 4 -> 4 bytes padding
write_date | timestamp | 8
active | bool | 1 -> 7 bytes padding
After each row uses 32 bytes (8 bytes saved per row):
attname | typname | typlen
-------------+-----------+--------
id | int4 | 4
create_uid | int4 | 4
write_uid | int4 | 4
active | bool | 1 -> 3 bytes padding
create_date | timestamp | 8
write_date | timestamp | 8
Of course, when more columns are present, the space savings depend on
the alignment of the other columns.
closesodoo/odoo#88084
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Since commit [1], we should use domain instead of _get_http_domain().
However _get_http_domain() checks if the domain exists which is not the
case in commit [2]. It only impacts databases having multiple websites.
[1]: https://github.com/odoo/odoo/commit/7d8a8ddea0b363732f2177ad589a3e0e10e2fb6c
[2]: https://github.com/odoo/odoo/commit/ee71cdff0786d5c41fbcc50894cd06811d3d8d5b
Steps to reproduce:
1. Install the eCommerce app
2. Add a second website
3. Keep the domain field of the website empty
4. Set the website field of a product to the website.
4. Click 'Go to Website'
Current behavior before PR:
- RPC_ERROR: Odoo Server Error
Desired behavior after PR is merged:
- Redirected to the product's page
closesodoo/odoo#88067
X-original-commit: 18c8a97ac986753728462b374a1c327bc9597a37
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This patch solves memory problem on exporting `account.move.line` records:
while export method invalidate cache for `account.move.line`, it keeps cache for
`account.move`, which may lead to memory error.
opw-2764457
closesodoo/odoo#88060
X-original-commit: 80c65498adf05b37d91207e0b59c781c6057f64b
Signed-off-by: Raphael Collet <rco@odoo.com>
Reproduce:
* Create default analytic rules
* Create a quotation/sale order.
Before:
Default analytic rules were not added on sales orders, like they are on
invoices and purchase orders.
After:
Same behavior on all documents.
This behavior was mistakenly removed during a refactoring:
https://github.com/odoo/odoo/commit/3c67bb20feb42f16799b7491411e213b818c4f83
opw-2800936
closesodoo/odoo#87980
X-original-commit: 0598eb70c13310d79202607e3bf46f82a85d6935
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This commit replaces raw SCSS with default Bootstrap classes, in
order to reduce code lines and to increase performance.
Task-2812497
Part of the overall v16 SCSS optimization/restyle, task-2704984
closesodoo/odoo#87796
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit
On mobile, clicking on a powerbox item called the first command.
After this commit
On mobile, clicking on a powerbox item call the clicked item command.
task-2751059
closesodoo/odoo#88059
X-original-commit: 03638e4d46941bb4751ac2d6df8c08cb4cc2208e
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
`this.root.el` can become undefined, so it should always be guarded.
closesodoo/odoo#88053
X-original-commit: 2e634bb431642fbe21b61d61354c85282c365d40
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When using an internal transfer to move some products between two
warehouses, the forecasted inventory becomes incorrect
To reproduce the issue:
(Let WH01 be the existing warehouse)
1. In Settings, enable "Multi-Warehouses"
2. Create a second warehouse WH02
3. Create a storable product P
4. Update its quantity: 1 x P at WH01/Stock
5. Create a planned internal transfer (the warehouse does not matter):
- Source: WH01/Stock
- Destination: WH02/Stock
- Operations:
- 1 x P
6. Mark the transfer as Todo
7. Consult the Forecasted Inventory report:
- Filters:
- Forecasted Stock
- Product: P
- Group By:
- Warehouse
Error: The line for WH02 is missing and the line for WH01 is incorrect
(qty is 1 for next days while it should be 0)
The report used (`report_stock_quantity`) does not handle this transfer.
Because both locations (source and destination) are defined, the SM is
not considered as an in-move or out-move:
https://github.com/odoo/odoo/blob/07f0ffad6ecc08f4165902db45ae96e4b41199e8/addons/stock/report/report_stock_quantity.py#L38-L43
Moreover, it would be hard to change the SQL view to generate two lines
(one 'in' and one 'out') from the same SM (the internal move).
The graph on the forecasted report of product P is also incorrect (it
uses `report_stock_quantity` to get the data, so if the user selects a
specific warehouse in the filters, the result will be incorrect)
So, the user should only avoid to transfer some products between two
warehouses if the internal transfer is a planned one.
OPW-2752017
closesodoo/odoo#87965
X-original-commit: 7f56063f6fe63a70d3e23b9c5fb486cc0958dd3e
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Steps to follow
- Use a browser timezone of GMT +2
- Create a pricelist ending in an hour with a matching product
- Add the pricelist to advanced pricelists in the POS settings
- Open a POS session
- Add the aforementioned product
- Apply the pricelist
-> The custom price is not applied
Cause of the issue
`date_start` and `date_end` are stored in utc
They are then off by the amount of the offset in the browser timezone
opw-2794490
closesodoo/odoo#88056
X-original-commit: 2fcecef406540323a753df5d802fb15a7546efdb
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Fix errors when adding attachment to records with read only permission:
Current behavior:
1. Error adding attachment to records with read only permission.
2. The message is not as clear as version 13.0
closesodoo/odoo#88036
Expect: Only display the message "You are not allowed to upload an attachment here." if you do not have permission to upload files.
X-original-commit: 8385f192873cfd33f311e00d9074571f1b3810a7
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
If a warehouse is set to a route like default 3-steps, updating the MO's
quantity to produce won't update the outgoing picking from
post-production to stock.
Since the quantity is now changed in the following pickings, no need to
put a warning in those pickings for the quantity change as their moves
quantity were automatically updated.
Task-2797359
closesodoo/odoo#86572
Signed-off-by: Arnold Moyaux <arm@odoo.com>
During the merge process of a negative move, it can deplete the quantity
of several existing moves (with positive quantities).
This is change is to make sure that a picking that would be depleted
this way becomes then cancelled, since no moves within would still be
relevant, as all moves would be set to 0.
Task-2797359
Part-of: odoo/odoo#86572
When updating the quantity of a manufacturing order,if multiple steps
were related to to its components, the changes would not be propagated
to them as no procurements were made.
So if updating the quantity of a two-step MO, the quantities from its
components within the MO would be updated, but not the ones from the
related picking.
Task-2797359
Part-of: odoo/odoo#86572
no need to select * in a query that looks like
select ...
from A
where exists(select * from B where ...)
we can instead use
select ...
from A
where exists(select 1 from B where ...)
closesodoo/odoo#88013
Signed-off-by: Raphael Collet <rco@odoo.com>
When the user create a button in the website builder through the
powerbox command "/button":
- call the editor fix for the link
- select the link
task-2704540
closesodoo/odoo#88010
X-original-commit: 92fcd5e15cf3fec96cdd2565157cd41ffd39a084
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Postgres is aligning columns to 4 or 8 bytes, depending on their type.
So, consecutive fixed-length columns of differing size will be padded
with empty bytes due to the alignment requirements.
Before this patch, columns where created in their definition order. Now,
they are ordered based on their size, in order to minimize the padding.
As an example, before each row uses 36 bytes (+24b header):
attname | typname | typlen
-------------+-----------+--------
id | int4 | 4
create_uid | int4 | 4
create_date | timestamp | 8
write_uid | int4 | 4 -> 4 bytes padding
write_date | timestamp | 8
active | bool | 1 -> 3 bytes padding
After each row uses 32 bytes (4 bytes saved per row):
attname | typname | typlen
-------------+-----------+--------
id | int4 | 4
create_uid | int4 | 4
write_uid | int4 | 4
active | bool | 1 -> 3 bytes padding
create_date | timestamp | 8
write_date | timestamp | 8
This saving scheme applies to all rows in all tables. We save between 4
and 8 bytes per row just on the usual create_uid, create_date,
write_uid, write_date.
closesodoo/odoo#87896
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, since https://github.com/odoo/odoo/pull/83574,
attempting to join a call through the channel guest page while being
logged as a portal user would give an acess error.
This commit fixes this issue
closesodoo/odoo#87995
X-original-commit: e6a637dc1d4e024c67b946fbe26a1b1e0dd144f3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit
Calling a command of the powerbox created a step that delete the input
content of the powerbox. That input content came back upon undo.
After this commit
The input content that select a command from the powerbox should
never come back upon undo.
task-2806849
closesodoo/odoo#87994
X-original-commit: 2da3d928ad4c7e7c285b753fb1241326089d45e7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since a recent commit[1], we introduced a standard publisher tour for
the slides. However, it was randomly failing sometimes while trying to
change image of the course. It happened because sometimes the double
click was performed before the page was ready to be edited, and so the
modal to change the image could not open.
This commit fixes the tour by adding extra_trigger in relevant step so
that before double clicking the image, we can make sure that the page
is ready for the edition.
commit[1] - https://github.com/odoo/odoo/commit/1af6dfe47baf1f42865203d0f3edafc6b50bbae8
task-2786661
closesodoo/odoo#87974
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit removes the access to stripe credentials through model
helper methods.
closesodoo/odoo#87972
X-original-commit: 61faa2b32880d60c8cfb7c7761cd313383c26a0b
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
Add quicksearch on 'Number' (name) and 'Reference' (ref) for the journal entries
Add quicksearch on 'Label' (name) and 'Reference' (ref) for the journal items
Even though those fields are already searched on in the 'main' quicksearch
of each view (i.e. 'Journal Entry' and 'Journal Item'), users might look to
specifically search on the label and reference, and get frustrated when they
won't find it in the available quicksearches.
task-2753889
closesodoo/odoo#87532
Signed-off-by: Laurent Smet <las@odoo.com>
- Steps :
Create 4 Services :
> Product Type : Service
> Create on Order : Project & Task
> Unit of Measure -respectively- :
>> Hours (H),
>> Days (D),
>> Units (U),
>> g (Other).
Create a SO with the for of them (1 uom_qty for each) and confirm.
- Expected :
For both the 'Planned Hours' on the Tasks
and the section 'Sold' of the Project Updates,
the conversion to time should be processed as follows :
H : qty = uom_qty [Hours]
D : qty = uom_qty * 8 [Hours]
U : qty = uom_qty [Hours]
Other : qty = 0 [Hours] or uom_qty [uom]
- Issues :
The Task linked to SOL (Other) has 1 Planned Hour i/o 0.
In Project Updates, uom (U) is Units i/o Hours
and uom (Other) is Hours i/o g.
- Fix :
This fix corrects everything as expected.
opw-2784992
closesodoo/odoo#87884
X-original-commit: 3cae83635067707a99141aad3cf6b0b6081e8159
Signed-off-by: Xavier <xbo@odoo.com>
Purpose
=======
Departure reasons could be used on business code (eg: payroll).
Currently the mapping is made based on the xmlid, but it could
happen for some customers to create several departure reasons
of the same kind. (ex: "Resigned - Salary" or even
"Resigned - Personal Reasons").
This commit uses the departure reason on _get_default_departure_reasons
to allow considering them together.
closesodoo/odoo#87662
Taskid: 2811192
X-original-commit: c7f46a4760fa2beb7d50b4b95f10e14a1a326423
Related: odoo/enterprise#25771
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Yannick Tivisse