This traceback raises when user changes the product type to 'consumable' in a
sale order and clicks the 'recorded' stat button.
To reproduce this issue:
1) Install 'sale_timesheet'
2) Create a new 'sale order'
3) Select any customer > Select a product with the 'service' type.
4) Click Confirm, then proceed to click the Create Project button.
5) Give any name to the project > Return to that sale order.
6) Now a 'recorded' stat button is visible > Click on that and create a record.
7) Return to that sale order > Go to the order lines, and for the previously
selected product, change the product type to 'consumable'
8) Once again, go to that 'sale order' and click on the 'recorded' stat button.
Error: "StopIteration: null"
[1] On the 'action_view_timesheet' method 'default_sale_line' variable is
getting a record with a condition of 'sale.order.line' is_service must be true
and 'service_policy' in 'order_prepaid' or 'delivered_timesheet' .
[2] But 'is_service' is getting value through a compute method in which
product type is equal to 'service'.
Because the user changed the type to 'consumable', the iteration ends with no
records and there is no default value. So it leads to the above traceback.
[1]
https://github.com/odoo/odoo/blob/69fca30bb4fb66e6d979ce5ddc1bff4db963ca71/addons/sale_timesheet/models/sale_order.py#L105-L111
[2]
https://github.com/odoo/odoo/blob/69fca30bb4fb66e6d979ce5ddc1bff4db963ca71/addons/sale_service/models/sale_order_line.py#L18-L20
sentry-4396433586
closesodoo/odoo#133903
X-original-commit: 062cec2175e5b22126b5c3be5acef5039ca1e804
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
There are cases where the result of `check_company_domain_parent_of`
is used in in a loop, leading to the parent_of relation being
recomputed once or even multiple times per iteration during SQL
evaluation.
Computing the parent relationship turns out to be fairly expensive in
worst case scenarios (e.g. lots of companies), so while precomputing
doesn't save much for a 1:1 situation (though it does make the job of
the expressions compiler a bit simpler), the ability to compute it
just once instead of say 140 times does make a huge difference in
e.g. some report renderings.
Nota: apparently `_check_company_domain` can be called with a string
because lol, so there's a special case for that.
closesodoo/odoo#133530
X-original-commit: 2f9ae135c9dd7cb09fa83fda7a9b304993cb3edc
Related: odoo/enterprise#46518
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Account codes are very commonly searched by prefix. This field used to
be implicitly indexed thanks to a unique constraint on `(code,
company_id)`, however the constraint was removed in #125642 rather
than converted to an index.
For the issue at hand `code` has a much higher discrimination power
than `company_id`, however it might make sense to also index
`company_id`, or to add compound indexes for `code, company_id` and /
or `company_id, code` for other work loads.
X-original-commit: 45c579908d90f6275b7d255d59c6555e8a57b959
Part-of: odoo/odoo#133530
*: pos_discount,pos_loyalty,pos_restaurant,pos_self_order
In a previous commit (669b9fcc2f) we added the
backend logic needed for creating combos in `pos`.
In this PR we add the combo functionality to the classic pos ui.
This means that products can now be grouped together and sold as a combo.
ex: Create a product called `Burger Menu` with type='combo'.This product will
have multiple combos associated with it, for ex:
- Drinks - will contain the list of drinks from which the customer can choose
- Main Course - will contain the list of main courses from which the customer
can choose
- Dessert - will contain the list of desserts from which the customer can choose
In the event that one of the products inside one of the combos is to be more
expensive, this product will have a specific `combo_price` which will be added
to the main combo product's price.
We add the relational fields `combo_parent_id` and `combo_line_ids` in the
`pos.order.line` model. In the previous example, `combo_parent_id` will contain
the `id` of the `orderline` of the `Burger Menu` product.
In many cases `combo lines` have to be handled together. For example, deletion
of an orderline containing a product from a combo implies the deletion of all
other orderlines containing products from that combo. This means that multiple
methods from the codebase had to be changed for this reason. Places that needed
changes for this reason:
- `split_bill_screen.js`
- `addProductToCurrentOrder()`
- `remove_orderline()` and `add_orderline()` from the `Order` js model
In this PR we also:
- improve the demo data such that it contains a `pos combo`;
- refactor the `ProductItem` component such that it relies on a stateless
component. This stateless component can now be used anywhere; ( it is now used
in the popup which allows selecting the desired combo products )
- add a new method called `is_pos_groupable` on the `Orderline` js model. Before
we relied on the product unit to see whether or not a product is groupable. We
now needed a new mechanism, which could account for different reasons for
which products are not groupable, such as belonging in a combo;
Note on price calculation:
- The idea is simple, imagine a rectangle divided into two parts. The whole
rectangle is the total order, whereas the two partitions are the orderlines.
- Now, imagine shrinking the rectangle by a certain factor. This shrinked
rectangle represents an order containing a combo -- because normally, a
combo results to smaller price. The two partitions are also shrinked by the
same factor.
- So the calculation will be:
- Nominal total price is calculated. This is the sum of the orderlines'
prices when they are added individually. This represents the whole
rectangle.
- Target price is derived from the combo product's price and selected
components' combo prices. This represents the shrinked rectangle.
- Reduction factor is computed as the ratio between the target price and the
nominal price.
- Each component's unit price is adjusted by multiplying the reduction
factor.
- When the unit prices of the components are computed, we now let the normal
price computation take place.
- A spreadsheet is prepared to show a sample calculation:
https://docs.google.com/spreadsheets/d/1iOdnaILnvKiaf2_z7jTijYiVfB_3mjKWjq6nOB70Un0/edit#gid=0closesodoo/odoo#129483
Task: 3430636
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Joseph Caburnay <jcb@odoo.com>
Changes in default can be bothersome, embed a full baseline
configuration for reliability.
closesodoo/odoo#27926
Signed-off-by: Pierre Masereel <pim@odoo.com>
Before this commit when we login as a user having project rights and open the
form view then 'project status' stat button isn't clickable. So in this commit
we have fixed that issue by giving group project user groups to stat button .
task-3432384
closesodoo/odoo#133927
X-original-commit: 0672824fb21e0a15dc951c46e317cb8cfc162ef2
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Dhrumil Shah (dhrs) <dhrs@odoo.com>
before this commit, from list view users can install
module using the button in list view and from the
action button.
initially the Install button was not available in the
list view and only option to install multiple apps was
from the action button.
but with the introduction of the button in list header
there is no need for an another server action to
perform the same.
after this commit, the activate modules server action
will be removed from the code and its related test
and also newly added Install button will be renamed
to "Activate" to align with the button in kanban and
form.
closesodoo/odoo#133544
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The commit f5ce6c5979e5fba1ccb7e30c8125cd7b97534925 introduced a regression that prevents closing
a POS session if the user does not have accounting and inventory
access rights.
opw-3487462
closesodoo/odoo#134055
X-original-commit: 6f43bc1972ac60e9365b40f53ee8966270e78848
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Bug:
When printing DDT documents for a delivery with a pricelist applied, the
total value shown comes from the product's original price and not the
modified pricelist price.
Setup:
- install `sale_management` and `l10n_it_stock_ddt`
- have a product P with a price A
- create a pricelist that where P has a price B
Steps to reproduce:
- activate DDT report printing
- create a quotation set the pricelist you created and the product P
- validate the quotation
- go to the associated delivery and validate it
- print the DDT report
You should see that the price mentioned on the DDT report does not
account for the pricelist. (price A is shown, instead of B)
opw-3171295
closesodoo/odoo#134017
X-original-commit: 9bdb0ed25dcef3f651a65abf0c4a8d9ce4e27851
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
When a user pays a donation with an empty amount value, the system
passes this value as an empty string, which is leading to a type-casting error
because an empty string cannot be directly converted to a numerical value like
a float.
Error: `ValueError: could not convert string to float: `
To handle this situation, we should use '_cast_as_int' and
'_cast_as_float' methods because these methods provide try-except blocks,
effectively handling these types of errors. This ensures that when an empty
amount value is encountered, the system manages the error.
sentry-4376573159
closesodoo/odoo#134026
X-original-commit: cae9f647b9e032aedfccc528d124acc639ecbf7f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In dashboard configuration, when you click on file of 'Data' section in
debug mode to edit, icons were duplicated.
This commit fixes the issue by getting rid of the same icons in
overridden template `web.ListBinaryField` from `binary_field.xml`
in order to remove icon duplicacy.
Additionaly, this commit removes unnecessary `<i>` tags and alters the
classes of `<button>` tags instead, to maintain the visual appearance
of icons (now they look the same as everywhere else).
Task ID : 3453198
closesodoo/odoo#134005
X-original-commit: 850e16cc415486507d1984ea08a04140ffba7c61
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
When sending a mailing we make sure to preserve comments (in particular
so that MSO comments can be read by Outlook). However this was not the
case when testing a mailing using the Test button in the form view.
task-3488162
opw-3290548
opw-3479234
closesodoo/odoo#133998
X-original-commit: 66b1dc38ced221d63f11827a217f9805827d5e65
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Current behavior:
The currency used to create the report is the one of the company. But
if you use a different currency in the pos config, the report will still
be in the company currency.
To fix that we check if all report's config use the same currency and
use it if it's the case we use the pos config currency. And if it's not
possible we use the company currency.
Steps to reproduce:
- Create a second pos
- Change the sale journal and the pricelist to use a different currency
- Open a session and make a sale
- Close the session
- Generate the daily report for the second pos
- The currency is the one of the company
opw-3463280
closesodoo/odoo#133996
X-original-commit: 3af535d9008c4d839ede2b5117230fa4a19b538a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Issue:
------
When adding a file to an employee's work permit ("Private Information tab"),
the file name is the "value" of the file.
This is not meaningful for the user who will download the file.
Solution:
---------
Use the `filename` attribute to determine the field of `hr.employee`
to be used to get the file name.
As the original file name doesn't exist in an existing field,
we can use a "generic" file name with a non-stored computed field.
opw-3458842
closesodoo/odoo#133981
X-original-commit: 2f49ec86fcd8191f92153069ae242c329a5cdf0c
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
I missed a critical issue in #133708: various users had discovered
they could already fix description issues by adding an XML declaration
to their document which is very cool (though technically not really
valid).
What is a lot less cool is that lxml gets *extremely* unhappy when
asked to parse *strings* with an encoding declaration, raising a
ValueError, so the purported fix breaks on any module which does that,
which seems to include a lot of OCA modules.
Gate the encoding guessing by bailing if the document has an XML
declaration, in which case we just assume the author knows what
they're doing and we leave them alone. For extra safety, check the
encoding declaration in ascii and utf16. Could also have checked for
BOMs, but lxml seems to not care about them overly much (in fact it
seems to prefer them decoded which is odd).
Also same as non-utf8 descriptions, mark XML declarations as
deprecated (because it's a hack to make UTF8 descriptions work which
is not necessary anymore).
closesodoo/odoo#133968
Reported-by: @rezak400
X-original-commit: fd353d7d0104431208b91603431e41ef4a6e54bb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The purpose of this commit is to make fieldDependencies are readonly by default.
This avoids making fields unintentionally editable. If the field is editable,
it will be sent during create/write, which is what we want to avoid.
Use case:
Go to a form view with 2 fields "a" which is readonly and "b" which has
"a" as fieldDependencies.
Before this commit:
Record Datapoint thinks that field "a" is editable
After this commit:
Record Datapoint thinks that field "a" is readonly
closesodoo/odoo#132247
Related: odoo/enterprise#46691
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This traceback raises when user tries to send an invoice without attachments.
To reproduce this issue:
1) Install 'Accounting'
2) Open any existing 'Invoice'
Note:- Invoice should not be in 'Draft'
3) Click 'Send & Print ' button an wizard will be opened.
4) Click on 'Send & Print' button of wizard.
5) Now repeat the step 3
6) This time delete the Invoice Attachment and click on 'Send & Print' button
of wizard.
Error: 'A traceback appears': 'can only concatenate list (not "bool") to list'
On '_get_mail_params' method 'attachment_ids' is getting
values by concatenating 'mail_attachments_widget' and
'invoice_extra_attachments_data'.
See:-
https://github.com/odoo/odoo/blob/27c1384e1209339158f56c82bebf99a5b64811f4/addons/account/wizard/account_move_send.py#L434-L448
Because of user delete the 'Invoice attachments' in wizard, 'mail_attachments_widget'
will return false and it leads to above traceback.
Sentry-4305060652
closesodoo/odoo#133953
X-original-commit: f08da6fdfa881ec3e80d6fc14dddaa8df3c529ed
Signed-off-by: William André (wan) <wan@odoo.com>
The traceback arises when a user deletes an attachment that the referenced in
the `account.move.send` model's `mail_attachments_widget` field, and
subsequently, the cron uses `mail_attachments_widget` to send invoices.
Steps to produce:
- Install account.
- Open Invoicing > open any invoice > click on SEND & PRINT > click on SAVE.
- Add an attachment > refresh the page.
- Go to attachments > delete the attachment which you have uploaded.
- Let the cron `Send invoices automatically ` run automatically.
ERROR: Traceback will appear MissingError Record does not exist or has been
deleted.
A `mail_attachments_widget` is a `JSON`storable field (Line 1) of the
`account.move.send` model. `mail_attachments_widget` carries data like the
attachment's ID, name, and mime type. Cron utilized the
`mail_attachments_widget` field to retrieve attachment data when sending an
email with attachments. `seen_attachment_ids` is a list of IDs (Line 2) of
attachments prepared using `mail_attachments_widget`.
This commit fetches only existing attachment records from the 'ir.attachment'
model for the attachment IDs present in the `seen_attachment_ids` list.
Line [1]- https://github.com/odoo/odoo/blob/0c95e064ca6384f57154bb12d3b4ef55ee1b4da3/addons/account/wizard/account_move_send.py#L76-L80
Line [2]- https://github.com/odoo/odoo/blob/d87dc624c33c8edd0eafc130b02a95fd91e58094/addons/account/wizard/account_move_send.py#L433-L439
Sentry-4315708399
closesodoo/odoo#133951
X-original-commit: 2486300538bc68075cba530bec481909af1aeb0d
Signed-off-by: William André (wan) <wan@odoo.com>
Issue :
When you try to import a big file it will display a blank error.
Steps to reproduce the error :
1-install inventory and e-commerce
2-go to products and import records
3-upload the file attached the ticket
Reason :
Before, there was a type included in the `reason` but now
it seems that the error has no type neither a message.
Fix:
I tried to just output a general error.
opw-3410954
closesodoo/odoo#133950
X-original-commit: 95cc5c84c3b4529cd269cf278fd4ab289f28685f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Previously, if you specified a min or max date for the datetime picker
and zoomed out to the month/year/decade view, it would disable some
months/year/decade incorrectly, this was caused by the code checking if
the beginning of the period was in the min-max range instead of checking
if the period had any overlap with the min-max range.
This commit fixes that by checking for overlaps instead.
closesodoo/odoo#133911
X-original-commit: 7cb61dca99be4b0a1c35f0ec762c1bda318ec043
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Kiosk parameters were not displayed when the pos_self_order_sale module
was installed.
This was due to an overridden function in this module that didn't call
super().
This is now fixed and functional.
closesodoo/odoo#133910
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Following commit 5620e47f80
1. workcenter automatic setting should be in demo data
2. Routings in demo data where set to active=False and enable
in mrp_workorder (OE) module. Since we enable by default
workcenters in mrp, we could remove this restriction
closesodoo/odoo#133908
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, in the kanban catalog view, when you make a groupBy
or update a record (click on the star), a crash is displayed.
Why does this happen?
The RPC for "sale_order_lines_info" is called during loadData of all dataPoint types.
Solution:
The RPC for "sale_order_lines_info" should only be called for DynamicRecordList.
closesodoo/odoo#133907
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this commit, partner information and utm fields are pre-filled when
creating an opportunity from the many2one `opportunity_id` in `sale.order`.
Task-3442793
closesodoo/odoo#133904
X-original-commit: fb70b749e655a22ff038dff06f6317d34381d33d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Adrien Milis (miad) <miad@odoo.com>
To begin with, there are two different fields.
- tracking_number: used with the kiosk or self so that the customer can
track his order.
- name (order_reference): classic order number, used to find them in the
odoo backend.
Example of tracking number:
- A1
- B1
Example of order_reference:
- Classic PoS: Order 00001-001-0001
- SelfOrder Mobile: Self-Order 00001-001-0001
- Kiosk: Kiosk 00001-001-0001
Two ir.sequences are used to generate these numbers. The first to
generate order_reference numbers per session, and the second to generate
tracking_numbers, which are common to all pos_configs and reset once
a day.
closesodoo/odoo#133902
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
This utils also exists in /core/utils/strings and the legacy
version was no longer used. Also remove the diacritics map which
is heavy.
closesodoo/odoo#133896
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, all python expressions in js were evaluated with
the same evalContext. Unfortunately, this is not possible for expressions
based on an x2many. The value of the x2many depends on whether the
expression will be sent to the server or not.
All expressions that are only used client-side, such as modifiers (readonly,
required, invisible), decorations, etc., must take virtual records into account.
For example, I define a button that must be visible when I have at least
one record in my x2many. So when I create my virtual record, I want
the button to become visible and not have to wait for the record to be
actually created.
For expressions sent to the server, such as domains and contexts,
we don't want them to take virtual records into account, as these are
not known by the server and could cause crashes.
Solution:
We have evalContext for expressions sent to the server
and evalContextWithVirtualIds for client-side expressions.
closesodoo/odoo#133718
Related: odoo/enterprise#46604
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
`waitForCondition` is written in a rather old style with a recursive `setTimeout` to handle the delay / debounce between checks. The code is rather hard to follow, and unnecessarily so: the code can be rewritten as an iterative async function which is a lot simpler.
Important change: `waitForCondition` now immediately checks for the condition instead of waiting `interval` milliseconds before doing so.
This is because the conventional usage is for it to be preceded by an `await triggerClick`, which includes an `await
waitForNextAnimationFrame()`. As a result there are good odds the click has already been processed by the time `waitForCondition` runs.
closesodoo/odoo#133645
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since the bank reconciliation report was removed, users no longer have a view of the journal items that impact the bank account without having a related transaction (account.bank.statement.line)
Since these cause a difference between the GL balance and the balance displayed on the journal dashboard, it is useful to display a link and the total of these journal items.
Only lines dated after the fiscal closing date, or the last statement date are included.
Task-3431843
closesodoo/odoo#129569
Signed-off-by: William André (wan) <wan@odoo.com>
Since a recent change at [1], a race condition seems to occur in the
gray colors palette test. Indeed, the change removed some delay in the
hackish code that is meant to wait for CSS reload.
Instead of restoring that otherwise-useless delay, this commit actually
fixes an extra_trigger that was incorrectly made in this test when it
was introduced at [2].
In any case, we should develop a more consistent and uniformed way to
wait for a CSS reload during edition test tours. It is currently done
different ways in different tests.
Note: this targets 16.0 to fix the wrong extra_trigger at the source,
even though [1] was only made in later versions.
[1]: https://github.com/odoo/odoo/commit/c6f8f781150902f585e16087f4a3868a855f3bd8#diff-795af7752739f5f510f74e5ee9b5b04d18a851062a1a6b7350cbe406e30a409dL18
[2]: https://github.com/odoo/odoo/commit/ddf2e74b4cf503ba651174bc7f280bf2f31a215e
runbot-24371
closesodoo/odoo#133889
X-original-commit: 6f32c27d52f877bde18628eb06475f56bdd95432
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
After the commit 60f41b1f83 scanning a product packaging at the
point of sale would not add the quantity to the order.
The getAddProductOptions function was updated to return a 'quantity'
variable, but the code was still using the old 'weight' variable for
the product packaging.
opw-3479699
closesodoo/odoo#133813
X-original-commit: 34dcfe24c93083c657d1a29806576f5fdcea4554
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
* = calendar, hr, im_livechat, mrp, project_todo, sms, snailmail,
test_mail
The parameter is too often specified with its default value to be worth
being a positional parameter.
Part-of: odoo/odoo#133717
* = calendar, im_livechat, project_todo, sms, snailmail, test_mail,
website_slides
The choice was made to have "trimmed text" check rather than "contains"
to have more robust tests, at the cost of slightly more effort to write
complete and unique asserts.
There is no direct speed improvement from this one, but it is one step
closer to removing jQuery.
Moreover, it will fix infinite loops in some situations, because jQuery
selectors would write attributes on the body, which would trigger the
mutation observer, which itself will call the selector again.
Part-of: odoo/odoo#133717
In this commit, current date is added in control panel breadcrums for calendar
week and calendar month views and this only for mobile screens.
If a week straddles two months then the two months are included in the wording
but in shortcuts (Aug-Sep 2023). In all other cases, the entire month and year
are included in the label (August 2023).
Task-3439201
closesodoo/odoo#133633
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
After the introduction of bootstrap, the floorplan edition style
changed. In this PR we want to make the floorplan edition look like
it was in saas-16.4.
closesodoo/odoo#133592
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Before this commit:
carry over field was two times one in radio and another in dropdown
After this commit:
dropdown carry over field is deleted from view
task-3481879
closesodoo/odoo#133327
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
When a product is purchased and received, valuation layers are created.
if we created a bill for the PO and change the product price, when the
account move is posted, `_apply_price_difference` creates new SVLs to
correct the product value.
Before this commit, the above scenario did not work with subcontracted
products, mainly because the valuation layer is linked to the finished
product move of the MO and not the incoming move of the PO.
This is fixed in `_get_valued_in_moves` where if the move is_subcontract
the orig move is the one linked to the valuation layer.
Now that we have the valuation layer, another issue arises, in the aml
`_generate_price_difference_vals` when the difference is calculated.
the `unit_valuation_difference` is not properly calculated because the
value in the layer includes the components value, so its incorrect to compare
it to the AML price, so we use `_get_layer_price_unit` to get the layer_price_unit
relevant to the AML, which in this case is the price of subcontracting (price on the PO)
Also for automated inventory valuation, when the inventory correction entry is
created it must credit the stock input account since the value of the
subcontracted product is corrected.
closesodoo/odoo#131565
Taskid: 3449931
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When the customer tries to move the video to the first position of the product
image. at that time, the error would be generated.
step to reproduce:
-Install the website_sale
-open Invoicing > vendors > Products > open any Product
-open sales Notepage
-click on add a Media
-past any video url > save it
-click on Go To website from the state button
-click on Edit button > again double click on the image
-then click on a right side position of re-order
error- Key Error:'video_url'
After applying our commit, if the customer got a validation error when
the customer attempted to swap the video into the product images at
the first position. There is a controller named
`/shop/product/resequence-image` which called, when the customer
changes the position of the video.
https://github.com/odoo/odoo/blob/3ce90ddf33f59a80de34cbafd05679d0817d0076/addons/website_sale/controllers/main.py#L582-L587
The `image res_model` will then receive the `product.image` model when a
customer moves a video from the third to the second position, and that model
locates the field known as `video_url`. However, when a customer moves a
video from the second to the first position, `image res_model` will then
receive the `product.product` model, and that model finds the same field but
does not have that field in it.
sentry-4393257638
closesodoo/odoo#133878
X-original-commit: 8a6a5a10befb98bfe21e5beaf60c9a303304486a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Versions:
---------
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- saas-16.4
Steps to reproduce:
-------------------
1. install the purchase and account_accountant modules
2. create a purchase order using a non-default currency;
3. create bill;
4. switch to a journal without set currency.
Issue:
------
Currency of bill automatically changes from the one used
by the order to the company default.
Cause:
------
The `account.move` model only looks at bank statements, journal,
and the company default when computing currency, ignoring any
value that might already be present in the invoice:
```
def _compute_currency_id(self):
for invoice in self:
currency = (
invoice.statement_line_id.foreign_currency_id
or invoice.journal_id.currency_id
or invoice.journal_id.company_id.currency_id
)
invoice.currency_id = currency
```
Solution:
---------
Try to retrieve currency from `invoice.currency_id` before
falling back on the company default.
opw-3434518
closesodoo/odoo#133867
X-original-commit: 114f328575000fd31f117c46381441d7ec0bca05
Signed-off-by: Levi Siuzdak (sile) <sile@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Apparently `lxml.html.document_fromstring` (and possibly other
`lxml.html` loaders) parses byte-strings as latin1 regardless of their
actual encoding, maybe because python2, maybe because there's a super
legacy html4 parser underlying it.
Either way that means ever since loading
`static/description/index.html` files was added 10 years
ago (4bf6a7ea4c) `_get_desc` has been
loading these files in latin1 rather than the utf8 most people would
expect.
Add an explicit decoding phase to try and load html description files
in UTF8. Fall back to latin1 in case there are description files which
are genuinely in latin1, or even just some random-ass broken stuff
which very much isn't utf8 (the extended-ascii encodings -- of which
latin1 is one -- will happily accept and mangle any input as every
byte value is valid, utf8 is a lot more structured).
Closes#127846closesodoo/odoo#133859
X-original-commit: 4dbc3b00e587f3d64cfd964a685f2bddd1b499ad
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- Enable different shipment methods (eg. Fedex US, USPS, DHLS US).
- Enable the 'Wire transfer' payment provider.
- Go to website, choose a storable product and checkout.
- On the last step of checkout, just click on 'Pay'
Issue:
The delivery method and cost is not the that was initially selected on the checkout page.
Reason:
On the start of the ``websiteSaleDelivery`` widget, we try to initialize the shipping cost of
every shipping methods in the list. But the we make a call on ``/shop/update_carrier`` which not
only gives the shipping cost but also change the delivery method of the order. As the loop is async,
the last random carrier to be computed is the one on the sale order when validating. So if we don't click on
the shipping method we want(to update the carrier) it will that last one which will be used.
Solution:
Use the ``/shop/carrier_rate_shipment`` which only returns a result with the cost without touching the
sale order.
opw-3457396
closesodoo/odoo#133846
X-original-commit: 7e2682b903b7908f0e86f66603e34d0b6fe90e52
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Eteil Junior Djoumatchoua (etdj) <etdj@odoo.com>
Nils Hamerlinck