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>
Commit "[IMP] core: don't save visitor default session" moved the geoip
from the session to the request with a deprecation warning. This commit
adapts the remaining modules to use `request.geoip` instead of
`request.session.geoip`.
Geoip is always set on the request but it can be an empty dictionnary in
case the geolocalization failed.
closesodoo/odoo#86015
Task: 2789035
Related: odoo/enterprise#25192
Signed-off-by: Julien Castiaux <juc@odoo.com>
Every request comes with a session, a dictionary that is persisted on
the filesystem and that saves various information such as the user
cart on the ecommerce.
When a user simply visits the website, a default session is created and
saved on disk, this bloats the filestore with many sessions. Creating
the session on-the-fly is cheaper than loading it from the filesystem.
With this work the default session is not saved on disk anymore unless
explicitly asked via `session.touch()`.
An exception to the statement "creating the session on-the-fly is
cheaper" is geoip, the ip geolocalization is not cheap. In this work,
geoip have been moved from http_routing/request.session.geoip to a
lazy property core/request.geoip. When requested the info is persisted
on the session. Like other keys from the default session, geoip will not
be persisted unless there is non-default stuff in the session.
Because the CSRF-TOKEN is based on the session-id, it is important the
session-id stays the same across multiples requests even when the
session is not persisted on disk. Even when a session is not persisted
on disk, the session-id cookie is still set so that the next session
created on-the-fly uses the same session-id.
Technical note regarding the session, it has been decided to drop the
session-snapshot protocol and to reintroduce a "modified" flag. It has
been decided not to use werkzeug's session (which natively comes with a
"modified" flag) and to keep our own session object. We decided to
extend MutableMapping instead of dict; using MutableMapping we only
have to override __setitem__ and __detitem__; using dict we would had to
override update()/pop()/... too.
Task: 2789035
Part-of: odoo/odoo#86015
Have a CL company setup
Issue a vendor bill
Then generate the credit note via 'Add Credit Note' wizard
Add a reason and confirm
Error will raise “You can not use a invoice document type with a refund
invoice”
As
https://github.com/odoo/odoo/commit/c9ff9d28ab75c02093ca54d9fbd1d2e203c5ee2e
for the invoice case
we need to add specific logic to handle credit notes in l10n_cl
opw-2801576
closesodoo/odoo#87946
X-original-commit: 0f1edf4d47d936c440e42fa105a8a5d6a75a8a77
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
In a subcontracting flow, the extra_cost on the subcontracted production
is read on the purchase line (via _get_price_unit() ) at the production
creation. In case the price unit on this purchase line change before the
validation, the stock valuation layer linked to the production will not
take this new value into account.
This commit ensures the price unit is the right one at validation
closesodoo/odoo#87726
Signed-off-by: Arnold Moyaux <arm@odoo.com>
During edit mode, editing the social media snippet induced losing the
whitespaces between the social media icons, thus reducing the space
between them. That space was however restored after saving.
After this commit, after each social media snippet change, we restore
a line break whitespace between each social media icon.
task-2739937
closesodoo/odoo#87933
X-original-commit: 3b8f11273bfa926172a4297785e58dfea92728d9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit replaces the thumbnail for the social media block. The
previous one was a duplication of the facebook thumbnail.
task-2739937
X-original-commit: f10c16948095fb1590decf7d7c2428993d2829d7
Part-of: odoo/odoo#87933
Co-authored-by: @Guillaume-gdi <gdi@odoo.com>
Icons of social media links should not be removable, this commit fixes
all header and footer template to respect this.
task-2739937
X-original-commit: 20d4b7452bf5de81c99c153eaf65a38a2f953503
Part-of: odoo/odoo#87933
This commit permits to:
- avoid DOM modification when starting options of social_media.
- remove the useless HTML related to the social media block.
- generate all available social networks that are present in the DB for
the social media block.
- delete DB social media if there is no value for it in the DB.
- display an alert banner in edit mode if the block has no link.
- use a shared variable for social media db urls in order to avoid too
much RPC.
- custom links are no longer togglable, only deleteable.
task-2739937
X-original-commit: f243bcbafb9291d94840795951c8fd51cab0cae1
Part-of: odoo/odoo#87933
mafo-odoo