-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Saas 17.2 #177
base: odoo-2
Are you sure you want to change the base?
Saas 17.2 #177
Conversation
|
|
26 similar comments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the downpayment price. Steps to reproduce: ------------------- * Create a quotation in the **Sale** app * In the **Point of Sale** app, open shop session * Create a downpayment for the order * Go back in the **Sale** app * Open sale order > Observation: The downpayment line has a price unit set * If needed, deliver the items * Create an invoice (regular invoice) * Confirm the invoice * Go back to the sale order > Observation: The downpayment line has a price unit of 0.0 Why the fix: ------------ The difference between the two flows (pos/sale) mainly resides in those few lines: https://github.com/odoo/odoo/blob/b3b1fe6a78f9e5b6f1d993b5aa2fed11e33c793e/addons/sale/models/account_move.py#L75-L85 `dpl.invoice_lines` will include 2 items when using the sale flow whereas only one when making the downpayment in pos. Downpayments from pos are not automatically invoiced and even if they are, the model `pos.order.line` does not have the field `invoice_lines`. However each downpayment **sale order line** that comes from the POS is linked to its downpayment **pos order line** with the field `pos_order_line_ids`. The only element left in `dpl.invoice_lines` will not be counted as it is included in `real_invoice` (the current invoice). The idea of the fix is to include the price unit of the downpayment made in pos in this sum. opw-4160111 closes #186965 X-original-commit: 370f3bc Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com> Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record => The "New" button disappears, but the "Save" and "Discard" buttons are not displayed closes #187149 Note: reported during the mobile tests conversion to HOOT in master. X-original-commit: 4f32523 Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. Also the other UI strings were in all caps and have been changed to capitalized strings. opw-4266444 closes #186980 X-original-commit: d9f83b5 Related: odoo/enterprise#73688 Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Versions -------- - 16.0 (sale_product_configurator) - 17.0 (website_sale_product_configurator) - saas-17.2 (website_sale_product_configurator) Steps ----- 1. Have 2 products with variants; 2. for both, add the other as optional product; 3. in eCommerce, add one to the cart; 4. select the other in the product configurator. Issue ----- The attributes get messed up due to first product being listed twice in the wizard, once in the cart, and once as an option for the second product. Solution -------- Front-end: Get the IDs of the currently displayed product templates, and pass them to the controller when fetching additional variants. Back-end: Before rendering the configurator template, update the cache to remove the currently displayed products from the added product's `optional_product_ids` field. Re-add them after rendering is done. opw-4071002 closes #187103 X-original-commit: 598f393 Signed-off-by: Valentin Chevalier <vcr@odoo.com> Signed-off-by: Levi Siuzdak <sile@odoo.com>
We were misconfiguring some accounts in ec localization: - Sale and purchase journals default accounts - Missing default valuation accounts on Adjustement and Production locations opw-4127252 closes #187150 X-original-commit: 3895719 Related: odoo/enterprise#73776 Signed-off-by: Florian Gilbert (flg) <flg@odoo.com> Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Part-of: #186990 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
closes #186990 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Some users are using custom domains in their loyalty programs. This include using fields that are not loaded in the PoS. This will fix the specific usecase of one client. But this could be improved and fields should be loaded dynamically based on the needed fields. opw-4262960 closes #186840 X-original-commit: 87d8f74 Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com> Signed-off-by: Robin Engels (roen) <roen@odoo.com>
When adding a rules in loyalty program that had a product set, if you try to refund an order containing this product you would get an error Steps to reproduce: ------------------- * Create a loyalty program with a rules that has product_ids set to any product. * Open PoS and make an order with the product set on the loyalty program * Validate the order * Try to refund the order > Observation: You get an error saying you cannot refund giftcards or eWallets Why the fix: ------------ This was happening because `trigger_product_ids` is related to `rule_ids.product_ids`. And when checking if a product is a giftcard or eWallet we first checked that `trigger_product_ids` was set. Now we only check the type of the program linked to a product. opw-4206226 closes #184319 Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
|
The Send & Print dialog will not consider attachments that have the same name as removed ones. Steps to reproduce: - Create an invoice - Confirm it - Action menu > Print > Invoice, save the file (e.g. INV_2024_00001.pdf) - Click Send & Print, wizard will open - Select Email only - Remove the generated attachment (INV_2024_00001.pdf) - Add the INV_2024_00001.pdf attachment saved before - Send the email Issue: The invoice will not be attached to the email (you can check in the chatter). This occurs because we filter out attachments by checking their names, and the name is the same as the auto-generated one. opw-4260237 closes #187202 X-original-commit: 73a3893 Signed-off-by: John Laterre (jol) <jol@odoo.com> Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Current Behavior: When an invoice is sent via Send & Print, is_move_sent is set to True. If the move is reverted to draft, is_move_sent is set to False. After that, if the invoice is resent via Send & Print, is_move_sent is not set to True again. To reproduce: 1. Optional: add the field is_move_sent to the view, to see its value 2. Create and confirm an invoice (is_move_sent = False) 3. Send it via the Send & Print button (is_move_sent = True) 4. Reset move to draft (is_move_sent = False) 5. Confirm and send it again (is_move_sent = False) Desired behavior: is_move_sent should be set to True after being sent via Send & Print, even if it is not the first time the invoice is being sent. Fix: We don't need to set is_move_sent to False when the move is reverted to draft. opw-4245126 Backport of #170713 closes #187242 X-original-commit: 1b4b3b7 Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com> Signed-off-by: Louis Gobert (loug) <loug@odoo.com>
Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is calculated correctly considering the vendor's delivery lead time. - Change the language of the database to a different language. - Repeat the replenish process. - Observe that the schedule date is not calculated correctly. Solution: - Replaced route name check with action check in `_get_date_planned` for better reliability, as action-based conditions reduce errors compared to route name comparisons. opw-4199660 closes #187056 X-original-commit: 387cd9a Signed-off-by: William Henrotin (whe) <whe@odoo.com> Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
…pany branches To reproduce the issue: 1) Create a company A, with a branch B 2) Define a currency rate for A, for currency C 3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown Branch companies use the rates defined on their root, so it should be displayed here. closes #187290 X-original-commit: 8bed71d Signed-off-by: William André (wan) <wan@odoo.com>
Step to reproduce. 1. Drag and drop a Contact Us Form 2. Select the form action as : " Apply for Job" 3. Select a field Type : "Activities" or "Kanban Stage" 4. Now on other field set visibility depending on this field 5. Now set the visibility options. -> Visibility value shows ID instead actual value/name. Prior to this commit, fields with conditional visibility showed the record's ID instead of its display name when the dependent field was a checkbox or radio button. This commit fix the issue by displaying the displayName of the record instead ID. task-4267217 closes #187042 X-original-commit: 88594c6 Signed-off-by: Serge Bayet (seba) <seba@odoo.com>
When a user visits a product page, the product gets marked as "recently viewed" after 8 seconds. This delay is too long, as a user can realistically view the product and navigate away before the 8 seconds have passed (in which case the product isn't marked as recently viewed). In particular, this is problematic when the website contains a "recently viewed products" carousel, where the user expects to see all products they recently viewed (even if they didn't stay on the product page for 8 seconds). We decided to reduce the delay to 0.5 seconds, which is long enough to prevent the product from being marked as "recently viewed" if the user visits a product page by mistake and immediately navigates away, but short enough to prevent problematic behaviors such as the one mentioned above. opw-4114364 closes #187282 X-original-commit: 7528304 Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
Steps: - Create a dynamic attribute with some attribute Lines - Create a product with attributes set to the new attribute - Change cost price and save - Reload the webpage Issue: - Cost price changes back to 0 Cause: - `_compute_template_field_from_variant_field` is called on `_compute_standard_price` which sets the value of field to default (false) for variant_count=0 Fix: - Cost price will be invisible for variant_count=0 opw-4054647 closes #187288 X-original-commit: 7f24aa1 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com> Signed-off-by: Dev Reshamiya (dere) <dere@odoo.com>
Steps to reproduce: 1. Have multiple companies 2. Create a multiple employee allocation 3. Connect to the other company: you should be able to find the allocation This commit further restricts multi-company access to allocations, so that it is accessible only when at least one of the employees on the allocation have the same company. task-4241723 closes #187085 X-original-commit: e7b2692 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Issue: - When picking up a SO in POS, the discount on products sold with a non groupable UOM disappears. Steps to reproduce: - Create a SO in the sales app. - Include a product that has a UOM of which the uom category is not grouped in POS (g for example). - Add a discount to the product. - Pick up the order in POS. - Notice that the discount is not applied. Solution: - In `_onClickSaleOrder` I set the discount on the `splitted_line` before adding it to the orderline. opw-4133659 closes #185508 X-original-commit: 69bf04a Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com> Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Steps to reproduce: - Create 2 storable products: Final product (FP) and Component (COMP) - Put 10 units of COMP in stock - Create a Bill of Material for FP: - raw move: 10 x COMP - 1 operation: "Register COMP" - Add an instruction on your operation: - type: "Register consumed component" - Product To Register: COMP - Create and confirm an MO for 1 Unit of FP - Go to the shopfloor > "Register COMP" - Change the quantity to 3 > Validate > Go back to the MO the quantity of the raw move is still 10 Cause of the issue: Clicking on "Validate" as well as on "Continue consumption" will trigger a call of the `_next` method with `continue_production=False` and `True` respectively: https://github.com/odoo/enterprise/blob/e86b97f57e2388b3b65326cecedd3c14ca02ddb1/mrp_workorder/models/quality.py#L346-L352 However, if you underconsume, a new move ine will be created for the remaining quantity in both cases and it should only when you `Continue consumption`. Note: If you underconsume, and change the quantity of the raw move without changing its original demand. As such, its state will itself change. Hence, if you come back to the MO, the reservation sate of the MO will be recomputed and be updated from assigned to confirmed. However, as the raw move is picked it should not alter the reservation state of the MO anymore: https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/mrp/models/mrp_production.py#L613 This is the purpose of the community PR. opw-4216910 closes #186782 X-original-commit: 67a8e00 Related: odoo/enterprise#73577 Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce: - Install "l10n_ch" and switch to the Swiss company - In the Accounting settings activate the QRcodes on invoices - Change the name of the Swiss company - Create an invoice - The old company name is still displayed next to the QR code Cause: The field displayed is the field `account_holder_name` which is not updated when changing the company name. Solution: As the field `account_holder_name` is not supposed to be shown anymore in 18.0, we can display directly the partner name. opw-4273688 closes #187104 X-original-commit: 30db866 Signed-off-by: John Laterre (jol) <jol@odoo.com> Signed-off-by: Mathieu Coutant (mcou) <mcou@odoo.com>
Steps to reproduce: - Enable Analytic Accounting and Anglo-Saxon Accounting in the settings - Create a storable product - Set inventory valuation to Automated on the product's category - Add a cost to the product - Create an invoice with the product and add an analytic distribution - When the invoice is confirmed, the distribution is also applied to the CoGS line. For example, in an invoice where the product’s sale price equals its cost, the account plan will show a balance of 0 (debit = credit). After this fix, the account plan will show a balance of 10. Task 2008567 led to the commit 3590efa, which removed the analytic distribution from the stock interim account. However, the expense line was not modified accordingly. opw-4177695 closes #187370 X-original-commit: 13abc6e Signed-off-by: William Henrotin (whe) <whe@odoo.com> Signed-off-by: Louis Gobert (loug) <loug@odoo.com>
Steps to reproduce the issue: ============================= - Set the company of the website to one that uses (euro) currency. - Open the website editor - Drag a banner block and a products carousel block under it - Set the last template to the products block (last one in the list) - Try to edit the title of the banner block - One of two keystrokes are reverted Origin of the issue: ==================== When we added content, we do historyStep which calls sanitize on the target (the editable), which will sanitize the non editable elements inside it and have `oe_unremovable`. observerApply now will mark this._toRollback as true so in the next keystroke it will revert the changes and so on... Solution: ========= We should not unwrap content for `oe_currency_value` spans opw-4252743 closes #187310 X-original-commit: 53e547e Signed-off-by: David Monjoie (dmo) <dmo@odoo.com> Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
When we try to print multiple invoice who have multiple pages and have H2 title in the comments, the system treats the document as separate files, resulting in error: `AttributeError: 'NoneType' object has no attribute 'getValue'`. Steps to reproduce: - Create an invoice without any attachment. - Create another invoice, ensuring that its printout spans multiple pages, and add an H2 title in the comments (narration). - In the list view, attempt to print both invoices. - Ensure that the report being printed contains a value in the "Save as attachment prefix" field. The issue arises because the presence of multiple H2 headings causes the system to treat the document as separate files. Consequently, the condition `if has_same_number_of_outlines and has_top_level_heading:`` is not satisfied, which results in a stream to be None. opw-4247013 closes #187383 X-original-commit: b127643 Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com> Signed-off-by: Louis Gobert (loug) <loug@odoo.com>
Product images are lazy-loaded on the cart page, causing them to be displayed later than the rest of the page. As a result, some parts of the page were shifted once the image was loaded (since the image had no size before loading). This change wraps the image in a fixed-size container to avoid the layout shift. Incidentally, this change also fixes some alignment issues when the cart contains images with various aspect ratios. opw-4029017 closes #187398 X-original-commit: 1715723 Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
|
The UBL file could contain SO or PO information if the invoice is linked to one. The MyInvois platform does not support this information and return a validation error if it is provided. This fix will update the template in order to remove this information from the file. closes #187360 X-original-commit: a620727 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com> Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr