Arf14 #78977
Open
Arf14 #78977
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Description of the issue/feature this PR addresses: Fixes #76177 Current behavior before PR: Before this commit, There will be tracback on adding new Journal Item if there is not date on Journal Entry. Desired behavior after PR is merged: Now we use current date to as fallback to convert currency. closes #76178 Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Some emails are wrongly formatted mainly due to old servers. If Final-Recipient header is void or wrongly encoded it currently crashes. This fix ensure there is no crash, even if bounce detection could be incomplete. Task-2641572 PR #76159 Closes #75618 Co-Authored-By: Thibault Delavallee <tde@odoo.com>
When body does not contain any tag or content parsing currently fails with an ``lxml.etree.ParserError``. To avoid that we can improve condition about void body: stripping void characters allows to avoid that traceback. Task-2641572 PR #76159 Closes #75625 Part-of: #76159 Co-authored-by: Thibault Delavallee <tde@odoo.com>
As create_uid has no value on mail.compose.message model when being in onchange or new mode, 'Mail Compose Message Rule' record rule may crash. In this commit we fix that issue by adding a value for create_uid. An unit test is added to ensure it effectively fixes the use case. Steps to reproduce this warning: 1. Create automated action for the 'mail.compose.message' model 2. Try to open 'Email compose Wizard' Warning: "Due to security restrictions, you are not allowed to modify 'Email composition wizard' (mail.compose.message) records. Records: mail.compose.message,NewId_0x7f8e99762310 (id=NewId_0x7f8e99762310) User: USERNAME (id=2) This restriction is due to the following rules: Contact your administrator to request access if necessary." Task-2641572 opw-2628005 PR #76159 Closes#75369 Part-of: #76159 Co-authored-by: Thibault Delavallee <tde@odoo.com>
…t types
Purpose of this commit is to highlight an issue that may happens easily with
`crm` that is made generic here within `test_mail`.
`crm` alters the context when creating a new record adding in this case
`default_type` to it][1]. The returned record contains that altered context.
his results in other records created from it trying to assign that same default
value for `type`. This is a very common name for fields, and happens to exist
in `ir.attachment` too.
If you create an alias for incoming leads in your DB with default values
`{"type": "lead"}` (something very common) and then an email comes to that
alias that contains an inlined base64 image, the attachment creation process
would simply fail.
Obtained error is ``ValueError: Wrong value for ir.attachment.type: 'lead'`` .
[1]: https://github.com/odoo/odoo/blob/272602193f5647f7f2270ed6ec68777625a139dd/addons/crm/models/crm_lead.py#L310-L311
X-original-commit: 890a91f
Part-of: #76159
Co-authored-by: Thibault Delavallee <tde@odoo.com>
When having an active livechat, we could end up with a lot of query errors like ``` 2021-08-30 [...] "POST /web/dataset/call_kw/mail.channel/channel_get HTTP/1.0" 200 - 104 0.151 0.075 2021-08-30 [...] ERROR production odoo.sql_db: bad query: UPDATE "mail_channel_partner" SET "write_uid"=2,"write_date"=(now() at time zone 'UTC') WHERE id IN (365007) ERROR: ERROR: Could not serialize access due to concurrent update ``` Avoiding unnecessary writes helps reducing concurrent updates. Task-2641572 PR #76159 Closes #75745 Part-of: #76159
When merging partners through the ``base.partner.merge.automatic.wizard`` wizard, messages and followers are merged. However activities are not probably because its underlying model is "newer" then messages and followers. This commits fixes that behavior. Task-2641572 PR #76159 Closes #71654 Part-of: #76159 Co-authored-by: Thibault Delavallee <tde@odoo.com>
Merge fixes coming notably from community reporting.
Containing
[FIX] mail: handle wrong Final-Recipient header in incoming emails
[FIX] mail: handle parsing of void body in incoming emails
[FIX] mail: fix ACLs issue with mail composer in new mode
[FW][IMP] test_mail: test models with type do not mess with attachmen…
[FIX] mail: prevent useless write when pinning a channel
[IMP] base: merge activities of merged partners
See sub commits for more details
Task-2641572
closes #76159
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Activate multicompany - In the company switcher select all company - Launch a pos session --> Issue all rpc request are make in all companies (len(self.env.companies) != 1). It create some error with taxes, fiscale position, ... closes #76393 Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
…d.fields Steps to reproduce the bug: - Open a customer invoice I for a customer C - Remove the country from the address of C - Click on button Print & send on I - Set the country of C with CTR - Click on Update and send Bug: The country of C was not saved. opw:2633425 closes #76023 Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Before this commit, When user with restricted rights tries to edit frontend page and without changing anything click on save button generate traceback due to invalid return type. - After this commit, On hitting save button on restrict mode resolve the traceback by changing function return type to promise. task-2379101 closes #66357 Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Issue: When viewing a pdf in a website_slide, in certain conditions ( odoo detect the slide is externally embedded), a <iframe> code block is displayed on the pdf rendering it really hard to read. As a work around, one could click on the "<\> Embed" button to make it disapear Steps to reproduce : 1) Run a local odoo server with the website_slides module 2) Set up a ngrox tunneling service to your localhost and good port 3) Find or create a **document** slide and get its id (<slide_id>) 4) Access the slide via the website url on the slide 5) Go down the page in the Share tab and copy the iframe -Replace http by https in the src attribute of the iframe if necessary 6) go back to the dashboard, open the inspector and add the iframe in the body of the webpage -> The slide is correctly detected as non embed 7) Access your Odoo database with the ngrox https forward (example : https://0dfc-2a02-a03f-6b9b-b300-bd6c-8048-90f1-3f25.eu.ngrok.io) 8) Repeat step 3 to 6 included -> The slide is detected as embed, so a <iframe> text area appears and make the pdf hard to read Alternative steps to reproduce : 1) Run a local odoo server with the website_slides module 2) Go to the usual http://localhost:8069/ to access your database and navigate to a PDF slide in eLearning 3) Change the localhost in the URL to 127.0.0.1 (Example http://localhost:8069/slides/slide/gardening-the-know-how-1 becomes http://127.0.0.1:8069/slides/slide/gardening-the-know-how-1) and press Enter to go to the new URL 4) Change back the 127.0.0.1 to localhost and press Enter to go to the new URL 5) You might have to repeat the back and forth between the two domains -> The slide is detected as embed, so a <iframe> text area appears and make the pdf hard to read Why is that a bug: It makes the PDF unreadable unless we know that we must click on that button, it really shouldn't be like that opw-2499110 closes #76447 X-original-commit: 0e9975d Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
Usecase: - 2 warehouses 1 and 2 - Create a route with a rule from inter-warehouse to WH2 - Create a picking type for WH1 for stock to inter-warehouse - Create a planned transfer with 2 stock.move in the wH1 new picking type -* Go back to inventory overview - Click on process on the picking type WH1 -> inter-warehouse -* Process the picking created before - Go to WH2 delivery You see 2 pickings for each stock.move despite they share the same data (procurement group, source and dest locations) If you don't do the steps bewteen *, you only have 1 picking. It's due to the context of the views that is propagate to the new picking created by push rules. opw-2533718 closes #76438 Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
A while back, the behavior of this setting was changed from a related field to a computed as a fix to various issues with: cb9f48d The setting's value synchronization with what is displayed on the setting's page is broken, since its behavior changed with commit: 2ccc735 . It resets to its default value for the default website when editing a secondary one and is not only confusing but breaks the setting in some scenarios. When changing the auth_signup_uninvited setting, the changes are correctly reflected and not reset to default upon changing the website we are currently editing. task-2612686 closes #76262 Signed-off-by: Romain Derie (rde) <rde@odoo.com>
…operation from the 'print invoices' actions Before, clicking on 'print invoices' or 'print invoices without payment' on a posted misc operation raised an error message saying that only invoices could be printed. However, the pdf file still got generated and could be found as attachement on the move. With this commit, we don't generate the file anymore in this case. closes #76509 X-original-commit: 4c06b3c Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
It is currently impossible to create a MO from a mobile if there are
some work orders
To reproduce the issue:
1. In Settings, enable "Work Orders"
2. Create two products P_finished, P_compo
3. Create a BoM:
- Product: P_finished
- Components:
- 1 x P_compo
- Operations:
- Create a new one
4. Switch to mobile mode
5. Create a MO with P_finished
Error: When saving the MO, a Validation Error is raised "The operation
cannot be completed: - Create/update: a mandatory field is not set.
[...] Model: Work Order (mrp.workorder), Field: Unit of Measure
(product_uom_id)"
For a work order to be created, the request needs to provide two
additional fields: `product_uom_id` and `consumption`. When setting the
product P_finished, an onchange is triggered and does not return
`consumption`. `product_uom_id` is returned but not included in the save
request (because the field is declared as `readonly`)
OPW-2557181
closes #76228
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Up to odoo 10.0, feedparser dependency was optionally used in the cli of vendored html2text.py (see https://github.com/odoo/odoo/blob/10.0/addons/mail/models/html2text.py#L437) - Since 11.0 (67c17cb), vendored html2text.py has been removed in favor of maintained package - Turns out the feedparser part in html2text was dead code for a long time anyway (see Alir3z4/html2text#220) - So we can safely drop this dependency closes #76273 X-original-commit: 271b946 Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Currently we are getting all records of mailing.mailing instead of getting only records with mailing_type=mail. This bug was produced by commit[1]. Now we have computed only that records which have mailing_type = mail, So we can get perfect count in mail stats button in campaign. commit[1] -> 3f6625e Task-2417993 closes #74841 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, if the survey participant does not answer questions of type: - simple_choice - multiple_choice - matrix The system does not register any survey.user_input_line with the "skipped" attribute set to True. Meaning that this question's answer will not appear in the survey statistics as skipped (in fact it will not appear at all). This commit makes sure we correctly save a user_input_line set as skipped=True when not answering to those types of questions. A unit test has been added to make sure that we consider every non-answered question type as properly skipped within the survey statistics. Task-2622869 Part-of: #75586
Currently, if the user configures his survey with questions of type 'simple_choice', 'multiple_choice' and 'matrix', but doesn't configure any selectable choices, the survey result page can crash. This is not really a "standard" use case but this commit adds a few checks to avoid a complete traceback and instead give empty data results. Task-2622869 closes #75586 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
closes #76087 Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
1. Define a product [TEST] with automated inventory valuation (AVCO) 2. Define a landed cost product in the same way 3. Create a RFQ for [TEST], Confirm and Receive product 4. Create Bill, add the landed cost on the bill 5. Confirm the Bill and create the landed cost (from transfer of point 3) 6. Create a SO for [TEST], confirm, delivery and create the invoice 7. Generate product margin analysis, [TEST] will be present 8. Register a payment for the invoice (it should have the status 'In Payment') Generate product margin analysis again, [TEST] entries will be missing This occur because, when the invoice is in 'in_payment' state the records are not taken into account opw-2631974 closes #76449 Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
1. Create a bank payment P01
2. Create a second one P02
- Journal: Bank
- Amount: 123
3. Edit P02:
- Journal: Cash
- Amount: 456
Error: A UserError is raised "Cannot create unbalanced journal
entry[...]" This change should be possible.
When changing the journal, the account of the associated moves lines are
not updated. Since the amount is also changed, in
`_synchronize_to_moves`, `_seek_for_lines` is called and tries to find
the liquidity lines thanks to their `journal_id` and their `account_id`
(which, as said above, isn't updated). This lead to incorrect results
and thus, incorrect behavior.
OPW-2568002
closes #75784
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Issue: When changing the bill date (invoice_date) of a vendor bill, the due date (invoice_payment_term_id) is not updated correctly Steps to reproduce : 1) Install Accounting, Purchase 2) Create a vendor bill 3) (debug) Edit the view, remove the invisible attr for the div with label invoice_payment_term_id 4) For the vendor bill, in that order, set the Vendor, then the due date to 30 days, then bill date, then add a product 5) Due date is now set to 30 days after the bill date 6) Change the Bill Date -> Due Date stays unchanged opw-2627686 closes #76068 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Bug introduced by this commit: f05db8b Steps to reproduce the bug: - create a journal entry with 4 ”account.move.line”: - two `”account.move.line”` with accounts of type ('receivable' or 'payable') > with the amount of both in debit or both in credit - two `”account.move.line”` with accounts other than the type ('receivable' or 'payable') - save - duplicate the `“account.move”` - validation error will be triggered: https:github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L3209-L3211 Problem: The payment terms must be recomputed only if the `”account.move”` is an invoice OPW-2642826 closes #76655 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When making a payment intent from Adyen terminal with the POS, the payment intent was validated by Adyen but Odoo stopped polling because a connection failure happened. With this fix we use the remaining_polls already implemented to get the adyen status with a interval of 3 secondes. If after 3 tries of 3 seconds each it still fails we can retry manually. Related to dcb1e2b and f83d1b1 opw:2587625 closes #76481 Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Issue : When selecting mrp_operation as picking_type, the product variant is not changed Steps to reproduce: Install Quality, MRP Disable variants Edit View: Form (debug mode) and remove groups="product.group_product_variant" to show the variants (This is done so we can see the issue in the backend) Set a product Changing product changes the variant Set the operation to manufacturing Set another product -> The variant is not updated Why is that a bug: It can lead to some problems if the variants are disabled and then enabled at a later time for the company Side-Note: The original bug related to the related commit was not present in v13 as said in the related commit opw discussion Related commit 2dc2003 opw-2515100 (related to opw-2490412) closes #76690 X-original-commit: 441fb1e Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com> Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
Currently, DDT use the product_uom_quantity of product for the ddt move which is inaccurate in case of no-backorder change in quantity The fix correctly check if the done quantity is other than 0 for the delivery and if it is, use it as the delivery quantity opw-2663174 closes #78184 Signed-off-by: Florian D <fdamhaut@users.noreply.github.com>
Release notes: https://github.com/odoo/owl/releases/tag/v1.4.7 closes #78644 Fix: memory leak in some templates Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
While installing 'crm_iap_lead_website' module, 'website_crm' module is automatically installed(auto install based on website and crm), and it introduces m2m field 'lead_ids' on visitors, as well as 'visitor_ids' m2m on leads. The issue is, 'website_crm' is installed automatically in this case, but does not depend on 'crm_iap_lead_website', and one can therefore uninstall 'website_crm' without knowing it may impact 'crm_iap_lead_website' (the 'lead_ids' field is defined in 'website_crm' and it is used in 'crm_iap_lead_website', and so trying to access it from 'crm_iap_lead_website' in this scenario will introduce a traceback). Other point to note: as we have no visitor field available in 'crm_iap_lead_website' (many2many added in 'website_crm'), we cannot manually search for leads as we do not have the information (we could make a fallback on visitor.partner_id if set, but that would be much low-level management just for a corner case). Considering above points, to avoid the traceback, instead of directly accessing the 'lead_ids' field, we simply check that whether the field exists or not. If it does not exist, we simply consider that no leads are attached to the visitor and we create the reveal view. If the field is there, the flow remains the same. Task-2655439 closes #78355 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In activity view, the deadline date that has no timezone is formatted from UTC to local timezone, so if the timezone is negative, we display by error the previous day (eg. 24 october instead of 25 october). With this commmit, we interpret the date in local timezone so there is no timezone issue. note: no test added since this only happen on browser with negative timezone which would be hard to test. note: this was fixed similarily in 13.0 with 0735547 but must have been lost in a refactoring. opw-2629681 closes #78681 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
before this commit, it was raising an error while try to preview the certificate after this commit, prevent the preview of certificate, as it is not possible to set the preview of certificate task- 2623276 closes #75116 Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
This commit ensure the pricelists are properly configured before launching a pos session.
Steps to reproduce:
- Have a V13 with point_of_sale
- Have minimum 2 companies A & B
- Select both companies in the company selector
- Go to Settings / General Settings
- Point of Sale
- Check Pricelists
- Go to Point of Sale
- Open a pos.config PC
- Set a Pricelist PL as Default Pricelist
- Go to Point of Sale / Products / Pricelists
- Open PL
- Set a company (must be different than PC)
- Go to Point of Sale
- Click "New session" on PC
--> Traceback
In V13, the traceback shows as "Traceback not available"
As from V14, the traceback is shown properly
A variant would be to start the session before changing
the pricelist company then click on "Resume" on PC
closes #78724
X-original-commit: 6099c36
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Steps to reproduce: - Install website_sale module - Enable discount and advanced pricelist in settings - Create product with sale price 0$ and set a website in - eCommerce + publish the product - Create pricelist PPP with Discount Policy as - "Show public price & discount to the customer" and selectable in the website - Go to the product and set an extra price of 10$ for the new pricelist - Go to the product in the eshop and select the pricelist PPP - Add the product to the shop cart Issue: The price displayed is 0$ instead of 10$. Cause: Since price_unit equal 0$, not possible to calculate the discount and therefore using the 0$ value. Solution: Use price of pricelist in case 'discount_policy' is 'without_discount' and price_unit equal 0$. opw-2652192 Forward-Port-Of: #78570 Cherry pick of 32d34ff closes #78701 Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
How to reproduce the problem: - Install hr_timesheet and create a project. - Create a task in the project, and assign a Partner as the Customer - In the Timesheet tab of the Task, add a new entry. Save the Task. - Edit the task again and change the Customer. Save again. -> the partner on the Timesheet entry did not change. With sale_timesheet, the Sales Order Item of the timesheet entry can be updated from the Sales Order Item of the Task, but it isn't the case with the partner, which is not logical. Solution : Now, the partner_id is computed and will automatically be updated from the Task's Customer/partner_id. If sale_timesheet is installed, it will first filter out the invoiced timesheet entry: we don't want to change an already invoiced entry. opw-2616784 closes #78577 Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Steps to reproduce: * Create PO * Confirm Receipt Date * Cancel PO * Draft and Confirm again Current behavior: * Button for Confirm Receipt Date is not visible Expected behavior: * Button for Confirm Receipt Date should be visible This is happening as we are not resetting the value of `mail_reminder_confirmed` on cancelling PO. With this commit, we reset value of `mail_reminder_confirmed` so use can Confirm Receipt Date again. closes #59674 Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
before this commit: applying readonly attribute on toggle_button doesn't work, toggle_button still clickable and value is still changed even though widget is readonly, there is no effect of readonly attribute on toggle_button widget. after this commit: if toggle_button widget has readonly attribute then it will not be clickable, button of toggle_button will be disabled so that user can easily understand that element is not clickable. task-2339995 closes #78793 X-original-commit: b153ded Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Due to floating point limitation, the quantities displayed in the forecasted report should be formatted to ensure the rounding. Issue example: (Need stock) 1. Create a storable product P 2. Update its quantity to 7.1 3. Consult the Forecasted Report Error: Quantities are "7.1000000000000005 Units". In this case, the floating-point issue comes from the method `float_round()` Another example: (Need purchase_stock) 1. Create a storable product P 2. Update its quantity to 0.1 3. Create a PO with 0.2 x P 4. Consult the Forecasted Report Error: The "Forecasted + Pending" quantity is 0.30000000000000004 Units. This field is directly computed while rendering the report, it's the sum of 0.1 and 0.2 which, in python, results in 0.30000000000000004 (floating-point issue) Since the rounding of these quantities are actually based on the decimal precision of the UoM, this commit may slightly change the report. Suppose the generic precision is .001 and the precision of "Units" is 0.01: if the quantity is 12.34, one zero will be added in the report: 12.340. However, these unnecessary zeros do not change the information that is initially displayed. Moreover, the UoM precision can not be greater than the generic precision, so we will never lose a part of the quantity to display. OPW-2611892 closes #78773 Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Expected behavior : The log note sent when received quantity is updated should take into account the quantity already received. Current behavior : The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock` Steps to reproduce the error : - Create a RFQ with few units of a Storable Product (e.g. 5 units) - Partially validate the receipt and create a backorder (e.g. 3 units) - Validate the backorder (e.g. 2 units) Log notes should be : `Received Quantity: 0.0 -> 3.0` `Received Quantity: 3.0 -> 5.0` But are : `Received Quantity: 0.0 -> 3.0` `Received Quantity: 0.0 -> 5.0` The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received opw-2600221 opw-2613116 closes #78286 Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
…es=False quotation_description on the sale order is copied from the product template, where it already is sanitize_attributes=False, and it has to stay like that because otherwise widgets like "tab" or "accordion" cannot be rendered correctly. This is also linked to a bug in the ORM where the _related_attrs weren't copied correctly. Related ORM PR: #78687 Ticket link: https://www.odoo.com/web#id=2487749&model=project.task opw-2487749 closes #78818 X-original-commit: ee90f6b Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>
… July 2021 with OSS Mod 303's grid 61 is now divided in 4 new lines: 120, 122, 123 and 124. Grid 61 isn't used anymore. This takes effect starting July 1st 2021; previous periods are unaffected. Doc: https://www.agenciatributaria.es/AEAT.internet/Inicio/Ayuda/Disenos_de_registro/Modelos_300_al_399/Modelos_300_al_399.shtml https://iranon.es/modelo-303-cambios-a-partir-del-3t-y-mensual-de-julio-de-2021/ OPW 2662476 closes #78651 Related: odoo/enterprise#21790 Signed-off-by: Josse Colpaert <jco@openerp.com>
…line Expected behavior : The order button should go green and active when you 'unskipped' an orderline Current behavior : The order button doesn't go green and can't be clicked when an orderline is 'unskipped' Steps to reproduce the error : First of all, you need to setup a PoS Restaurant with these options : ~ Bar/Restaurant ~ Enable `Table Management` ~ Enable and setup `Order Printer` with IP Address and choose Categories to be printed on. 1. Open a restaurant session 2. Pick a table 3. Select a product and put it on hold 4. Select the **same** product and order it 5. 'Unskipped' the product from step 3 Order button should be green and active but is unactive so the order can't be sent Previously, the condition was only based on the product_id so error occurs when multiline of the same product are handled opw-2557518 closes #78829 X-original-commit: 8159e5a Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
(Backport : fbf76c1) Expected behavior : Quantities are displayed in the same way on the delivery note regardless the stock picking stage. Current behavior : Quantities aren't displayed in the same way on the delivery note depending on the stock picking stage. (e.g. `2.00 Units` units when picking is in `Waiting` stage but `2.0 Units` when picking is in `Done` stage) Steps to reproduce the error : - Create a RFQ with few units of a Storable Product (e.g. 2 units) - Go to the Receipt and print the Delivery Slip and look at the quantities printed (e.g. 2.00) - Validate the Receipt and print the Delivery Slip again, quantities printed have changed (e.g. 2.0) opw-2578120 closes #78815 Signed-off-by: Arnold Moyaux <arm@odoo.com>
Purpose ======= Fix guest users receiving confirmation emails for events by "Public User". Specifications ============== Confirmation emails for events are sent by: - Organizer (if set) - Company email (if set) - The users's email - Odoo bot otherwise Task-2657588 closes #78849 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue: When returning a product sold that is only made of kits and
validating the return, the delivered quantities of the sales order was
set back to the full amount delivered
Steps to reproduce :
1) Install MRP and Sales
2) Create a BoM Kit for a new product [Nested Kit] that has one or
more consumable or storable product as component
3) Create a BoM Kit for a new product [Main Kit] that has
[Nested Kit] as component
4) Create a SO for [Main Kit], confirm, validate delivery
5) Check SO, 1 product is delivered (correct)
6) Go back to the Delivery, create a return for the delivery
(don't validate)
7) Check SO, 0 product is delivered (correct)
8) Now validate the return for the delivery
-> Check SO, 1 product is delivered (bug)
Why is that a bug:
Since the Main Kit was returned, the delivered should be 0 and not
the full amount initially delivered. It was set back to 1 because we
didn't look at the type of picking, when computing the quantity
delivered, the fall back considered that if all the moves were done,
everything was delivered, but it is the opposite when returning
opw-2542337
closes #78838
X-original-commit: e90452b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Some of the support scripts use xml-rpc calls to work on pos.session on Saas or SH databases (especially when needed to upload lot of offline orders in smaller batches) These scripts should be allowed to close any rescue session created during this process programmatically via xml-rpc. Our xml-rpc protocol does not allow to call function that return nothing closes #78909 X-original-commit: 834bed3 Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce the bug:
- install mrp_workorder
- Create a new work center which will work every day from 8:00-9:00
- Create a BOM with component and operation, which takes 24 minutes in your work center
- Create 4 MO for this bom
- Set manually scheduled date > 1 MO should have a different date than others, e.g:
- 3 MO → 01/dec/2021 08:00
- 1 MO → 02/dec/2021 08:00
- Plan the MO which has different date than others
The ```planned_end_date``` is not calculated correctly
Current behavior before PR:
MO_1 : 01/dec/2021 08:00 → 01/dec/2021 08:24
MO_2 : 01/dec/2021 08:24 → 01/dec/2021 08:48
MO_3 : 02/dec/2021 08:00 → 02/dec/2021 08:24
MO_4 : 02/dec/2021 08:24 → 02/dec/2021 08:24
Problem
The MO_4 should only last 20 minutes, while it lasts 23 hours and 48 minutes.
opw-2648065
closes #78377
Related: odoo/enterprise#21701
Signed-off-by: Rémy Voet <ryv@odoo.com>
WO are released in confirmed state, but the help message says that they are released in draft. opw-2609040 closes #78890 Signed-off-by: Arnold Moyaux <arm@odoo.com>
Most uses (correct ones) of the `partner` context key content expect a `res.partner` recordset as `partner` context value. This value is extracted during the pricelist price computation (but not used anyway...). But in one case, fixed by the current commit, a `res.partner` id is placed in the context, as `partner` value. In some cases, this may trigger "Comparing Apple and Oranges" errors, since `with_context` calls returns a new or existing environment, verifying whether an environment with the same values (user, context, ...) exists. During this comparison, the new context, with an id (int) as `partner` value, is compared with existing contexts, potentially including some with a recordset on the same key. Such a comparison fails on the lowest `__eq__` level, raising "Comparing apples with oranges" error. This commit fixes this case, by making sure the value put in the `partner` context value is always a recordset, and not an id. closes #78936 Note: In the future, this context key should be dropped because it's still a bad practice to put recordsets in the context. Forward-port-of: #78276 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Seems like depending the pillow version, the output image size could differ from one or two bytes. Now we check the expected size with a tolerance of +/- 1 byte. closes #78935 Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
1) Do not overwrite lines description if the line was not modified Fixes #78833 2) Correctly recompute prices on quantity change. When no new line was added to the SO through the matrix, the prices were not recomputed, even if the qty was modified for some products. The prices have to be recomputed in this case since pricelist provide rules based on minimum qty. Part-of: #78902
Same fixes for the purchase scope 1) Do not overwrite lines description if the line was not modified 2) Correctly recompute prices/sellers on quantity change. When no new line was added to the PO through the matrix, the prices/sellers were not recomputed, even if the qty was modified for some products. closes #78902 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
prueba merge