Step to reproduce:
- Create PO with an item rounded to 0.01
- Deliver 0.48/1
- Open Accrual Expense Entry
Current Behaviour:
- Order line is not taken into account due to rounding error
- Wizard is empty
Behaviour After PR:
- Qty is correctly rounded and appear as expected
- Order line is taken into account
opw-2720161
closesodoo/odoo#82073
X-original-commit: 85c2ab58d9ce1ccefd02f8214937a649285fde4a
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Steps to reproduce:
-Create a quote with 2 lines (same product - different lead time).
-When a partial delivery is made (e.g., 5 of 10), Odoo places the operation related to the remaining undelivered quantity (5), on the last line in the Operations list.
-When the next delivery is made, Odoo deducts the quantity from the first operation in the list instead of from the line whose deadline is closest.
Current Behaviour :
Odoo assign button assign quantity to the first move line in the list.
Behaviour After the PR:
Odoo assign button assign quantity to a move line based on the priority, the closest deadline and the id.
opw-2657048
closesodoo/odoo#82062
X-original-commit: 430f4f2ca1cebaea62415ee72bf4369684abbfaa
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Inside a scrollable popup, the scroll was not correctly triggered when
moving one of its snippets through drag and drop.
This commit correctly defines the SmoothScrollOnDrag.$scrollTarget when
a modal is shown.
task-2431469
closesodoo/odoo#82040
X-original-commit: 844051168311ac0c3e8640dda2a90545e373c98d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
- Install stock with demo data
- Log in Chicago company
- Chicago partner has inter-company transit set on Customer and Supplier
locations
- Jeff Lawson (partner address of chicago warehouse) has Customer and
supplier locations set instead of inter-company transit.
It prevents the following usecase:
- Enable synch SO and PO between chicago and SF company with automatic
confirmation
- Create a product with route Buy and MTO
- Create a PO in company chicago that buy to SF comapny
- Validate the PO
You have an error with rule since it try to pull from intercompany
transit instead of customer
However if you log in San Francisco company Jeff Lawson has
inter-company transit set while it should not.
It happens because during the demo install the partner is added through
a write and the company is not provided and the code was missing a part
in that case.
closesodoo/odoo#82006
X-original-commit: 46c49ce4f6c9677463425981f01b69117c11943e
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When a kit is exploded to `stock.move` the quantity is rounded half-up
for every move. But during the invoice. The quantity to invoice on
kit is rounded up so it could result in differences between the
inventory valuation and the cost of the product
closesodoo/odoo#81778
X-original-commit: 1a56d6646d44861cea238ae67d2a7becb36c01b3
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Fix for task 2620026.
_get_bom_component_qty function is only referred to once in the whole odoo app,
which is on addons/sale_mrp/models/account_move.py#22.
The result returned from this function is used as a multiplier to quantity
to convert into the expected UoM. However, the quantity being referred to on
_stock_account_get_anglo_saxon_price_unit (qty_invoiced, qty_to_invoice), are
already converted into the SO Line's product's default UoM. In this function,
it however tries to convert 1 from SO Line's UoM to BoM's UOM.
With this, if Product UoM=x, SO Line UoM=y, BOM UoM=x, in the function _stock_account_get_anglo_saxon_price_unit,
the quantities will be multiplied by the same factor twice, resulting to the incorrect computation of price_unit to follow.
X-original-commit: d7c2f59dc6e769bd6e8c0e53fe1e4f9df16bbe52
Part-of: odoo/odoo#81778
Step to reproduce:
- Settings -> Mail channel -> any chat-type channel
- Go to Members
- Add an user
- Refresh the page
Current Behaviour:
- Traceback
- Chat are designed for 2 users and you should not be able to add more
Behaviour after PR:
- Can only edit members of channel if it's not a chat
- User error if try to add more user
- Fix traceback if there is too much users
opw-2717341
closesodoo/odoo#82044
X-original-commit: 85f7b7c1304222966610833dc325bc47f1c13158
Related: odoo/enterprise#23156
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Fixes an error happening near the end of the year with one of the test.
The error was introduced with 254d6a71e8
TaskId-2724172
closesodoo/odoo#82028
X-original-commit: 1de3a4bee7b1df4960694d0851e72ef2eecb98a9
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit introduces a tooltip to indicate to the user that he can
drag and drop the block into the page.
This tooltip is shown after a delay; if the user has started dragging
the block in the meantime, the tooltip won't be shown. Otherwise, it
auto fades out.
task-2431469
closesodoo/odoo#81430
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Steps to reproduce:
- Create an account group for a range for example from 100000 to 200000
- Now edit the group to have a range from 100000 to 150000
Issue:
The accounts with code > 150000 are still in the account group
Solution
Adding an other intermediary table to the query in order to take into
account the accounts which have no group_id
opw-2695533
closesodoo/odoo#82023
X-original-commit: 05c3cb8dbb7a9bf0f438d5ee687b92e8d934f26b
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
The translation of purchase.order().notes name (Terms and Conditions) is
wrongly done in bulgarian since 2016
(d14efd562b).
opw-2719178
closesodoo/odoo#82005
X-original-commit: b0be51f8b2fc1c9422aa543d03a321936bb8f667
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
*: web_editor
Hovering the shadow mode option reset the entire shadow instead of just
previewing the mode change.
Related to opw-2701512
closesodoo/odoo#81980
X-original-commit: cae1b99052ded63a3e532b92419236dd51056fd8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Install `website_hr_recruiment` module
- Go to `your_website.com/jobs`
- Activate Edit mode and add a "3 Columns" block
- Select one of the columns and set the shadow to `None`
Issue:
Shadow is not removed, and by default the "outset" mode is selected.
Cause:
When we check the state of the shadow with `css('box-shadow')`, it
will always be set because a custom css 'box-shadow' is set by the
module website_hr_recruitment on card element, and therefore the value
will always be either 'inset' or 'outset'.
Solution:
If widget value is set to '', replace `box-shadow` style to 'none'
(only if needed) so it will override the style from css file.
opw-2701512
X-original-commit: 212d8ec10bb48e8fd7de3d3ff7660447b968c62a
Part-of: odoo/odoo#81980
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit, if a theme record (eg `theme.ir.ui.view`) was deleted,
its copy_ids would not be.
While this is perfectly normal and wanted behavior when this is done in a
website context (to not alter other websites), it shouldn't be the case when
performing a theme update through CLI/Migration (or if the user find a way to
update the module through the UI).
Fixes https://github.com/odoo/upgrade/pull/3048
task-2593407
opw-2680866
opw-2685951
opw-2685124
opw-2679040
closesodoo/odoo#81953
X-original-commit: 3146dd72e6cb07d6e78ca763325f13dd54de0086
Related: odoo/design-themes#548
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Some theme are enabling an header template. When doing so, they also disable
the default header template.
But this is not enough, as the user could have changed that template and it is
not the default one anymore.
Then, updating that theme (UX, CLI, Migration) will raise a traceback.
Step to reproduce:
- Create a website and install theme avantgarde
- Enter edit mode and select Magazine header template
At that point, update the theme, either:
- Through the UI, on theme switch screen, click on Update
- Through CLI, just run a `-u theme_avantgarde`
-> A traceback will be raised about an xpath error, as both the magazine header
template and the hamburger header template are active at the same time. Only
one template is supposed to be activated.
The issue also impact migration, as migrated website can't be accessed due to
the xpath error on rendering.
Theme being impacted (at least): Avantgarde, Graphene & Nano
Note that when installing one of those themes for the first time on a website,
the error won't occur as `_reset_default_config()` will be called through
`_theme_remove()`.
Note that this fix will ensure the correct template is set (and all others are
disabled), but the scss variable won't be correctly set (as it would be if that
template change was done through the right panel).
This is not that much of a problem (considering what it solves), any later
change from the user through the right panel will solve that mismatch.
Fixes https://github.com/odoo/upgrade/pull/3048
task-2593407
opw-2680866
opw-2685951
opw-2685124
opw-2679040
X-original-commit: f18cd32a936829d8a059db0d259189503ee5317f
Part-of: odoo/odoo#81953
As the message is thought to be posted in chatter replacing returns with html break.
closesodoo/odoo#81937
X-original-commit: 6cb616d74f71951b3989880ae232702d2257d292
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
A portal user couldn't download a survey certificate
Steps to reproduce:
1. Install the Survey app and open it
2. Create a survey with a scoring and a certificate and copy the link
3. In an incognito tab, connect as portal and go to the survey
4. After completing the survey, try to download the certificate
Solution:
Change the call 'sudo()' to 'with_user(SUPERUSER_ID)'
OPW-2687625
closesodoo/odoo#81957
X-original-commit: 962919ec878b4e93b4dd8f01f029ce1366976d9b
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
The dutch COA is outdated and incomplete. Some accounts have wrong types, and some accounts are missing.
Correct the COA so that every account is correctly categorized.
Changes:
- Add and correct accounts in the dutch COA
- Add tag to 'bank suspense account'
Task id=2674603
closesodoo/odoo#81943
X-original-commit: d486d26cbd705cc5a2bff074d26308c0ecc9d798
Related: odoo/enterprise#23115
Signed-off-by: Laurent Smet <las@odoo.com>
Before, the system required a vat number on every partner, but that
is not required. We need to send it as some other kind of ID however.
To clarify, a partner without vat is not for the simplified case only.
closesodoo/odoo#81942
X-original-commit: 2b164b8e5173ebbc80b8662a011ec48a7a06bcf5
Signed-off-by: Laurent Smet <las@odoo.com>
It's possible to confirm an invoice with an archived bank account of
the recipient. But it's not making any sense, since the bank account
is archived.
It's why we need to raise an error if the user want to confirm an
invoice with an archived bank account.
opw-2704605
closesodoo/odoo#81939
X-original-commit: 8b9ff034cb67b132cdb6736a5f18d70beb63c253
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Bruno-brsy <brsy@odoo.com>
Current behavior :
PDF Preview in document layout settings doesn't match the downloaded one (colors of div with the total and the columns displayed)
Steps to reproduce :
- Go to Settings
- 'Configure Document Layout' under Companies
- Set layout to Boxed
- Change the colors
- Download the PDF Preview
Reason :
- The columns for the unit price and taxes had the 'd-none' class so they weren't visible when printing the pdf preview. To keep coherence, if we see them in the preview we must see them in the pdf.
- Colors, especially the total div with a 'Boxed' layout, weren't taken into account for some elements in the preview. This is due to a character sanitized in the CSS, specifically '>' which becomes '>' for the '.row > div > table' selector.
OPW-2716089
closesodoo/odoo#81932
X-original-commit: 158c0ae425b3be446d81c3a6f4387b2d9426d10e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
In case the product is tracked and the "Ship Later" feature is enabled,
the lots defined on the POS order are not the same that the ones on the
SMLs of the associated picking
To reproduce the issue:
(Use demo data)
1. Create a product P:
- Type: Storable
- Tracked by lots
- Available in POS
2. Update P's quantity:
- 2 x Lot01
- 2 x Lot02
3. Edit the existing POS:
- Enable the "Ship Later" feature
4. Start a POS session
5. Add some products:
- 1 x P (Lot01)
- 1 x p (Lot02)
6. Process the order with the option "Ship Lated" selected
7. Open the associated delivery order
Error: The reserved lots are incorrect: 2 x Lot01 instead of 1 x Lot01 +
1 x Lot02
When creating such a POS order, if the feature "Ship Later" is used, a
method creates a procurement for each POS order line thanks to
`_launch_stock_rule_from_pos_order_lines`
https://github.com/odoo/odoo/blob/72d6431eb26654b697fc0379f4b6d7e305bb79fc/addons/point_of_sale/models/pos_order.py#L677-L680
Then, these procurements are managed by the standard process, which does
not consider the defined lots. This is the reason why it simply uses the
available quantity in the first lot.
OPW-2704352
closesodoo/odoo#81888
X-original-commit: bc59c4eb7ef6bc216474f39ef8e2634b4ab5ff42
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Part of code in `_create_move_from_pos_order_lines` ensures the creation
of the SMLs based on the SN defined from the POS session
Extracting this part of the code enables the creation of these SML on
already-created SM
Linked to OWP-2704352
X-original-commit: 648232a9b34324bbfe86e2c4cb69db127fe48a7a
Part-of: odoo/odoo#81888
Step to reproduce:
- Have a fleet contract that need renewal
Current Behaviour:
- A new activity is created everytime the scheduler is called
Behaviour after PR:
- A new activity is only created if there is no current renewal activity present when the scheduler is called
opw-2713537
closesodoo/odoo#81919
X-original-commit: 3610069ea2c10fccf8fcc82c384a2194c4702e06
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Steps to reproduce:
- Create two bank journals Bank-1 and Bank-2
- Create one Oustanding Payments and one Outstanding Receipts account for each bank journal
- Create and confirm an internal tranfer from Bank-1 to Bank-2 for 100$
- A second payment is created
Issue:
The account on the line in the second payment is the Outstanding Payments account of Bank-1,
it should be the Outstanding Receipts account of Bank-2.
After this commit, the second payment will take into account the account set on bank journal,
and if not set, the one set on company. Otherwise, an error is raised.
opw-2711252
closesodoo/odoo#81938
X-original-commit: 51b5a9d4e56d8d2300cf1ee91f8030c57a41a856
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
This PR allows the user to put a transparency effect on the mega menu.
The transparency effect did not work on the mega menu because
the container that contains the mega menu did not have transparency.
Note that the mega menu templates use a default background color
since [1] to not be transparent by default because of this commit.
[1]: 967d21a
task-2623335
closesodoo/odoo#77871
Related: odoo/upgrade#2929
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Error raised when trying to add the Wire Transfer payment method in eCommerce
Steps to reproduce:
1. Install the eCommerce app
2. Open the Website app
3. Click on "Set payments" on the eCommerce Dashboard
4. Select "Custom payment instructions", fill in the fields and save
Solution:
Remove the piece of code that raised the error
OPW-2687671
closesodoo/odoo#81929
X-original-commit: 25e153ab652f7a4bcc70e145b47bc138d9fb3790
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Invalid data provided at record creation were silently skipped by the
framework without triggering an error. This commit ensures that data are
no longer accidentally filtered and therefore that an error will be
raised if a key that does not match an actual field is provided.
This commit also removes the dead code that was detected thanks to these
changes.
closesodoo/odoo#81909
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before, the 'success' key was removed from the results
of the invoice processing and as such the invoice
was never put as successfully sent, but you sent it
again and again.
closesodoo/odoo#81911
X-original-commit: 853ff30b76a56bcb9af88256aac3a3ceb93bf562
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
In urllib3 1.25, an _is_key_file_encrypted method was added
where urllib3 checks if the keyfile is encrypted or not, but
urllib3 uses filenames, while we want to use the contents of cert.
So, in our case, this gave a traceback because it could not open
the file.
The final simple solution for now is to keep keyfile empty as
we store our info in certfile anyways already.
X-original-commit: f908171f91107a4972b29e575bb722c0dabf4ee3
Part-of: odoo/odoo#81911
Core client remains incompatible with CSP, however it can't hurt to
CSP the sub-resources.
Current scheme is simplistic, however if useful of necessary it could
be made more flexible e.g. there could be a map of mimetypes to CSP
configuration, that sort of things.
The origin parameter must be an absolute link (starting with a /)
To be consistent and always have a leading slash (and avoid relative
links if the developer forgot to add a leading slash)
All textual content generated by opening the tag must be flushed before
inserting the default content
closesodoo/odoo#81700
X-original-commit: effeba10787388ee0a3d153c984fab5731fc9b1a
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>
To reproduce an issue:
Open Recruitment Form from Surveys app. Share it with a recipient.
For example with Azure Interior.
Current behavior:
2 registrations are created, including an empty one.
Expected behavior:
Only 1 registration (for Azure Interior) should be created.
Task-2694600
Partial rewrite of odoo/odoo#81851closesodoo/odoo#81903
X-original-commit: a0a626253b62f01d6bbfe56b98fdedb2317b9598
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
