[IMP] web: split column_width_hook into dedicated module#636
Open
imanie383 wants to merge 321 commits intoVauxoo:18.0from
Open
[IMP] web: split column_width_hook into dedicated module#636imanie383 wants to merge 321 commits intoVauxoo:18.0from
imanie383 wants to merge 321 commits intoVauxoo:18.0from
Conversation
The EU OSS taxes were generated with the wrong l10n_es_type. - Install l10n_es and l10n_eu_oss. Then go to Settings and refresh the tax mapping in “EU Intra-community Distance Selling.” - In Taxes, filter by tax group containing “OSS.” All OSS taxes appear with l10n_es_type = sujeto. This is incorrect. The correct type should be “No Sujeto por reglas de localización” (see section 2): https://a3responde.wolterskluwer.com/es/s/article/version-3-05-del-moduloticketbai-batuz-de-a3erp-mejoras#OSS This commit adds the possibility of adding country specific field during the account_tax creation using chart_template -> fields mapping. opw-5009180 closes odoo#225459 X-original-commit: f743c12 Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com> Signed-off-by: Guillaume Teboul-Tornezy (gute) <gute@odoo.com>
Currently, an error occurs when a user tries to add multiple comma- separated new tags to a forum post. Steps to reproduce: - Install the `website_forum` module. - Go to: `Website > Configuration > Forums`, create a new forum, then click Go to Website. - Click on `Start by creating a post`, enter content, and set the `Tags` to `_test, retour affectif rapide`. - Click on `Post Your Question`. Error: ValueError: invalid literal for int() with base 10: 'retour affectif rapide' Root Cause: After PR odoo#169472, at [1], the code prepends an underscore (_) only to the entire input string instead of each tag. When multiple tags are entered, the backend receives a mixed list of values (e.g., ['__test', 'retour affectif rapide']), leading to an error during int() conversion at [2]. Fix: This commit updates the `onCreateOption` logic to prepend an underscore to each tag in the comma-separated input, similar to [3]. Also updated the test case at [4], to click `Create option` to save the tags. [1]: https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/static/src/js/website_forum.js#L54-L61 [2]: https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/models/forum_forum.py#L304 [3]: https://github.com/odoo/odoo/blob/ac93a25b216e6194895a64fe12c0d01f6833f743/addons/website_forum/static/src/js/website_forum.js#L69-L80 [4]: https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/website_forum/static/tests/tours/website_forum_question.js#L34-L37 sentry-6761920887 closes odoo#220058 Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Purpose ======= Making sure that, when typing a search term, all the results displayed in the search bar dropdown are visible on the page when clicking Enter. Specification ============= Previously, the search bar dropdown was displaying all the events where the name or description matched the search term. However, when clicking Enter, only the events where the name matched were displayed on the page (the ones where only the description matched were ignored). Fixing the issue by considering the description in the event search options. Task-5039221 closes odoo#226820 X-original-commit: f7a9129 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Signed-off-by: Amélie Dieudonné (amdi) <amdi@odoo.com>
This commit removes the phone number from the DIN5008 report layout. The customer's VAT is also no longer displayed in the customer's address section. The VAT is moved to another section. task-5049074 closes odoo#226967 X-original-commit: e0d57df Signed-off-by: John Laterre (jol) <jol@odoo.com> Signed-off-by: Sherif Gabr (sgab) <sgab@odoo.com>
Portal users can edit their opportunities. It is necessary to verify that they have access to certain information to avoid unexpected behaviour. task-5025295
Steps to reproduce: - Open any chatter with a message on mobile - Try to translate the message using the Translate mobile action => Throws traceback This happens because the component here is `MessageActionMenuMobile` instead of `Message`, and MessageActionMenuMobile does not have the `onClickToggleTranslation` method. This commit fixes the issue. closes odoo#223567 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
…ng contract Step to Reproduce - install hr_contract and hr_holidays module - go to employee -> contracts - Add 2-3 contract to a employee, which can be done by having contracts in different interval - set their stage to `running` - open Time off App Observation: - we receive a traceback Cause: - `_get_unusual_days` assumes that there is only one running contract - Hence with multiple contract, it raises traceback Fix: - Adjust the method to accept multiple contracts opw-5045306 closes odoo#225521 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Split payment taxes were not labelled correctly in the PDF's "Taxes" column, they were labelled as standard taxes. closes odoo#226588 X-original-commit: 78f9029 Signed-off-by: John Laterre (jol) <jol@odoo.com> Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
The kpi.provider:get_account_kpi_summary method should count draft moves by category, but also include posted moves that still are to be checked by the accountant. The categories should not be the move_type, but the journal_type. closes odoo#227091 Task-id: 5062431 X-original-commit: d7c63aa Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Test has been disabled in 18.0~master since March, it's even more broken in 19.0+ following odoo#225791 (migrated to a `setSelection` with a different protocol, but the tour was not updated to the new protocol). https://runbot.odoo.com/odoo/error/116797 closes odoo#227163 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If you have a company parent with loyatly programs and you try to confirm a sale order from a child company, an access error will be raised. Steps to reproduce: ------------------- * Create a loyalty cards program * Set company to the current company * Create a branch company for the current one * Switch to branch company * Create a sale order, no need to add products, just a partner * Try to confirm the order > Observation: Access Error: > Sorry, Mitchell Admin (id=2) doesn't have 'create' access to: > - History for Loyalty cards and Ewallets (loyalty.history) Why the fix: ------------ The access error is triggered upon creation of history lines: https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/sale_loyalty/models/sale_order.py#L106 Branches currently have access to the discounts & loyalty programs, the loyalty cards, rules and reward, from the parent company, we extend the access to include loyalty history. Another solution could be to create the loyalty history using sudo() if the coupon's program id is a parent of the current company. opw-5055999 closes odoo#226226 Signed-off-by: anko-odoo <anko@odoo.com>
Currently if the TicketBAI upload fails, a QR code is printed with the value `true`. Steps to reproduce ----- 1. Validate a POS order 2. Have a request exception occur during the TicketBAI post 3. Receipt is printed with an incorrect QR code Issue ----- `get_l10n_es_pos_tbai_qrurl()` returns None if the edi document is not accepted. This is then interpreted as `true` by the client and a QR code is printed. Solution ----- Explicitly return an empty string if the edi document is not accepted. closes odoo#227293 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
Before this commit, if CUPS raised an error when adding a printer in the `supported()` method of the printer driver, the exception would not be caught causing the printer interface to stop. This can happen for example if the filesystem is read-only or the printer has an invalid name. After this commit, we catch any CUPS errors and log them, allowing the printer interface to continue running. We also enter write mode before adding the printer to prevent any read-only errors. task-5086036 closes odoo#227209 X-original-commit: 2a8f2ce Signed-off-by: Louis Travaux (lotr) <lotr@odoo.com> Signed-off-by: Max Whale (mawh) <mawh@odoo.com>
X-original-commit: 68d3e89 Part-of: odoo#225956 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
closes odoo#225956 X-original-commit: 874a8a5 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without setting a company (making it a global project). 5. Enable both companies in the systray 6. Try to log a timesheet on the global project. issue: ------ A ValidationError is raised: "Timesheets must be created with an active employee in the selected companies." cause: ------ During `vals_list` preparation, the `company_id` value is overwritten here: https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/hr_timesheet/models/hr_timesheet.py#L381 If the project has no company set, `company_id `becomes False. This condition fails if the user has two employees and no company set (or if it is missing): https://github.com/odoo/odoo/blob/d3c7e51e94d98da9086a3817b157c4e125c80790/addons/hr_timesheet/models/hr_timesheet.py#L211-L215 solution: --------- Use `self.env.company` if company_id is missing(or False) in the vals. opw-4892449 closes odoo#227268 X-original-commit: 00ae93d Signed-off-by: Bommisetty Narendra (bona) <bona@odoo.com>
These tests are non-deterministic, we should not fail when running them. We simplify the API and remove asserts for linear behaviour. closes odoo#226278 Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
closes odoo#226577 X-original-commit: d727d06 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
closes odoo#226311 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When an invoice is being issued to a Foreign Customer, the Other Buyer ID (Other Buyer ID (BT-46) <cac:AccountingCustomerParty / cac:Party / cac:PartyIdentification / cbc:ID>) should be OTH and filled accordingly to avoid an acceptance warning from ZATCA. According to ZATCA, the value needs to be in alphanumeric format, even if the value does not follow the specific country's VAT format closes odoo#227199 Task-id: 5075005 X-original-commit: e04d9ac Signed-off-by: Khaled Fahmy (khfa) <khfa@odoo.com>
…lete sales orders closes odoo#227347 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Dragging and dropping a `fa` icon leads to traceback. This issue happens because in onDrop method, value of `htmlTransferItem` contains only a ZWS wrapped in a `<span>`. This span gets removed in `prepareClipboardData`, alongwith ZWS resulting in an empty fragment being passed to the `insert` method. The insertion of an empty fragment lead to the traceback. task-4882121 closes odoo#215194 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Cf odoo#226267 the "error condition" on the ws socket is that it's not present at all, not that it's `None`. So when used after a fatal error (e.g. in the context of trying to take a screenshot or take a screencast) these methods *can* in some cases trigger a compound failure and lose the original error because they fail on trying to access the ws to check if it's truthy. closes odoo#227425 X-original-commit: b66659b Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Fix runbot error in single app runbot-231469 runbot-231471 closes odoo#225147 Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Step to reproduce: - install Attendances app - turn on debug mode - go to Attendance -> kiosk mode - open the scanner Observation: - We get a traceback Cause: - we pass a extra prop to BarcodeDialog component - this raises issue from OWL when we have debug-mode on Fix: - reuse the actual `scanBarcode` method and remove the faulty one. opw-5064719 closes odoo#225738 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
…_line_ids
Traceback when no `repartition_line_ids` found in tax data.
Steps to reproduce:-
- Install `l10n_in` module with demo data.
- Install `l10n_account_withholding_tax` module.
Error:-
File /data/build/odoo/addons/l10n_account_withholding_tax/__init__.py, line 27, in _make_demo_tax
tax_repartition_lines = [line[2] for line in tax_data[purchase_taxes[0]]['repartition_line_ids'] if line[2]['repartition_type'] == 'tax']
KeyError: 'repartition_line_ids'
Root Cause: At [1], No `repartition_line_ids` found in
`tax_data[purchase_taxes[0]]`.
Solution: Select only purchase taxes having `repartition_line_ids`.
[1]: https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/l10n_account_withholding_tax/__init__.py#L27
closes odoo#227381
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Issue PDF reports fail when attachments are remote URLs or cloud storage resources. The `to_pdf_stream()` method expects local file data but receives boolean values from remote attachments, causing a TypeError. Solution Download remote resources before processing them in PDF reports. This ensures all attachments have accessible data regardless of storage type. Affected Reports - `account.report_original_vendor_bill` - Vendor bill reports - `hr_expense.report_expense_sheet` - Expense sheet reports Affected Versions - 18.0+ (17.0 theoretical; cloud_storage wasn't implemented, so doesn't make sense) Reproduction Steps Option A: HR Expense Report 1. Create HR expense record 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to hr.expense record 4. Generate expense report → TypeError occurs Option B: Vendor Bill Report 1. Create vendor bill (account.move) 2. Add attachment with type=url/cloud_storage pointing to valid PDF URL 3. Link attachment to account.move record 4. Print Original Vendor Bill → TypeError occurs Error Details ```python TypeError: a bytes-like object is required, not 'bool' at /odoo/tools/pdf/__init__.py:220 in to_pdf_stream from /odoo/addons/hr_expense/models/ir_actions_report.py:29 ``` Reference Client demo: https://drive.google.com/file/d/1HUvZqZ21NiX34T2IQhuVNbLP41xSV7jq/view OPW-5036638 closes odoo#226094 Related: odoo/enterprise#94477 Signed-off-by: Raphael Collet <rco@odoo.com>
some models use attachments for data for business logics for example, ``account_move.message_main_attachment_id.datas`` ``hr_expense_sheet`` will use all bounded attachments to generate report This commit prevents uploading attachments to cloud storage for some models if they ``_inherit`` or ``_inherits`` model ``mail.thread.main.attachment`` closes odoo#227165 Signed-off-by: Raphael Collet <rco@odoo.com>
Hyphens are generally omitted in ERPs, and just shown on the Identity card. Putting hyphens in the placeholder is actually misleading for users, and prevents validation through the IAP server and MyInvois Ref: https://en.wikipedia.org/wiki/Malaysian_identity_card#Structure_of_the_National_Registration_Identity_Card_Number_(NRIC) Task [link](https://www.odoo.com/odoo/project/967/tasks/5054821) task-5054821 closes odoo#225094 Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
New description paragraphs generated by the builder for the "pricelist" snippets were missing two expected classes. - "mt-2" was never applied, so all pricelist variants lacked the vertical spacing below product titles. - The boxed and cafe snippets also needed the `o_small` class to keep their text size consistent. Steps to see the missing "o_small": 1. Drop an "s_pricelist_boxed" or "Pricelist Cafe" snippet on a page. 2. Use Backspace to delete the text already present in one of the descriptions. 3. Toggle the "Descriptions" option off and on; the regenerated paragraph appears larger than expected because `o_small` is absent. task-5117864 closes odoo#229464 Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
task-5131034
Fix registration-based communications there are still checked and scheduled even after event is done. Expected behavior is: once event is done, do not send attendee communications anymore, since they are used for badges, QR codes, ... Event-based communications are still sent as they denotate post-event mailings. Since odoo/odoo@4ffa006 subscription-based scheduled communications are never set as done. Indeed this makes no sense: each new attendee resets the flag to "todo", as new communications have to be scheduled. This means ` ('mail_done', '=', False)` part of the last OR part was always truthy hence launching the scheduler. Now: mail_done is AND-ed with the part telling that either the scheduling is event-based, either the event is not finished. Task-5103885 closes odoo#227986 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When website_event is installed an anchor tag is added inside the event description which is guaranteed to break the url in the gmail client. We now quote the description appropriately so that there's no confusion. task-5092759 closes odoo#228359 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, there is no validation in place to determine when the label related to invoice_sending_methods should be added to the portal_my_details_fields template in the inheritance made in [1]. This results in the following: - For invoice_sending_methods, the label/message: 'You can choose how you want us to send your invoices, and with which electronic format.' is always displayed, even if the <select> to define the method is not visible. Now, a validation has been added to display this label only when necessary, in order to avoid user confusion. [1]: odoo@de567b6 closes odoo#200261 Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Issue: In this bug, the workorder duration being set to duration_expected is causing issues in backorder. To reproduce: 1- Create a Bill of Materials with at least two operations at two work centers 2- Create a manufacturing order and confirm it. 3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity. 4- In the second work order, the first operation is cancelled, Finish the 2nd operation 5- As you can see, the cancelled operation duration is set to expected duration which is wrong. Cause: This issue is caused because of: https://github.com/odoo/odoo/blob/8f0e40286da7b144bfa17880a257406dd8585e57/addons/mrp/models/mrp_production.py#L1774-L1779 Which if work.order.state is `cancel`, the duration will set to `duration_expected`. This will eventually cause issue here: odoo@8f0e402#diff-fac872ffb03b811c4976eb2e52991ec544265332df814d92cfda658a5b917423L348 which is fixed by not making the state into `progres` if the state is `cancel`. But that doesn't fix the fact that the cancelled workorder has duration set and it might cause inconsistencies in manufacturing costs. related: opw-4931653 closes odoo#229742 Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce: - Create a storable product “P1” - Create a manufacturing order to produce one unit of P1: - add any component - Mark the MO as done - Try to open the MO overview Issue: An error is raised because the MO has no BoM. But in the function we try to compute the missing quantity in the BoM's UoM, but since no BoM is linked, there is no UoM available. Error message: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure %(product_unit)s defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category." Fix: Skip the computation of missing BoM quantities when no BoM is linked, allowing the MO overview to be opened without error. opw-5112132 Opw-5105544 Opw-5119897 closes odoo#229707 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This error occurs when trying to make a payment again from the cart. Steps to reproduce: --- - Install the **website_sale** module (with demo) - Activate **Demo** payment provider - Go to Website > Shop > Add a **Warranty** product to Cart > View cart - Pay with Demo > Pay - Click the back button(chrome navbar)(Instantly) - Now again Pay with Demo > Pay Traceback: --- `ValueError: Expected singleton: sale.order()` At [1], this error occurs because **order_sudo** is empty. This happens when there is no product in the cart — typically because, upon clicking **Pay**, a sale order is created for the product, and when the user navigates back, the cart is empty. [1]- https://github.com/odoo/odoo/blob/125fc3028debb311e9f6ad25d8c46699b77525f0/addons/website_sale/controllers/main.py#L1307-L1312 sentry-5682671428 closes odoo#229858 Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Steps to reproduce:
- Install Accounting and Contacts
- Use a company based in Netherlands
- In Contacts, configure the company:
* eInvoice format: Netherlands (NLCIUS)
* Peppol endpoint: [anything]
* Reference ("Sales & Purchase" tab): [anything]
- Create a Dutch contact with a peppol endpoint and a reference
- Create an invoice for the Dutch contact
- Confirm the invoice
- Send the invoice
- Check the generated NLCIUS xml
Issue:
In the XML there are 2 "<cac:PartyIdentification>" for each party.
One with the peppol endpoint and one with the partner reference.
For "<cac:AccountingCustomerParty>", only one Party Identification
is allowed, triggering the following validation error:
[UBL-SR-16] Buyer identifier shall occur maximum once
Cause:
By default (UBL 2.0), the partner reference is used as Party
Identification.
But in the case of a Dutch partner, the peppol endpoint is also
added in BIS3.
Solution:
Only use the peppol endpoint for Dutch partners.
opw-5059667
closes odoo#226561
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
**Steps to reproduce:** - create a storable product with fifo category - update the cost to 200 - click on the on hand smart button and add a quant of 1 quantity - update the cost to 300 - click on the on hand smart button and update the quantity to 2 - the value should be 500, which makes a 250 value per product - open Inventory/valuation and search your product - group by product, select your product and click on "+" icon to open the revaluation widget - add 200 (so +100 per unit) - go back to the product form **Current behavior:** the cost is now at 400 **Expected behavior:** the cost should be at 350 (250 + 100) If we change the standard_price we should change it in accordance with the valuation **Cause of the issue:** In action_validate_revaluation, during the update of the standard_price, the current standard_price (set by the user and disconnected from the valuation) is used in the computation. https://github.com/odoo/odoo/blob/5118f7cb80744f901d7028dc75c29aba9591b83b/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L127 opw-5028848 closes odoo#228457 Signed-off-by: Steve Van Essche <svs@odoo.com>
…with a different tax. The logic introduced in odoo#127196 adds default taxes from "other" companies to products created without a specific company. However, because child companies (branches) share taxes with their parent company, when creating a new product using the parent company and setting a specific tax (different from the default), the default tax was incorrectly added back to the product. This happened because the logic considered the branch an "other company" and applied its default tax. FIX: Exclude branch companies from the domain when we set the default tax of other companies on the product. Steps to reproduce: 1. Create a branch company. (It will automatically have the same default tax as its parent). 2. With the parent company selected, create a new product, leaving the 'Company' field empty, and change its sales tax to any tax other than the default, and save. 3. Notice that the default tax is set again on the product. opw-5094415 closes odoo#229746 X-original-commit: 37056c7 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com> Signed-off-by: Mohamed Yousef Ahmed (myah) <myah@odoo.com>
Currently we're lacking tests for the Nilvera API integration. This commit adds a test suite that primarily focuses on testing that. Task ID: 4655864 closes odoo#228010 X-original-commit: 2dfcbe5 Signed-off-by: Ali Alfie (alal) <alal@odoo.com>
Issue 1 The validated email success banner wasn’t triggering the RPC call because Bootstrap’s `data-bs-dismiss="alert"` removed the element from the DOM before the handler could run. Issue 2 Closing the banner previously triggered `/profile/validate_email/close` RPC, which reset `validation_email_done` to false. This mistakenly caused the “email sent” banner to reappear, confusing users. Solution - Overwrite Bootstrap’s `close.bs.alert` event to trigger the RPC when the success banner is dismissed. - Set `validation_email_sent` to false so the banner stays hidden after being closed. Task-5049533 closes odoo#229890 X-original-commit: 997db69 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Incoming bounce email linked to a partner in the db is incrementing (in `message_receive_bounce`) the message_bounce value during the handling of the bounces (in `_routing_handle_bounce`) If later, an email linked to a partner existing in the db (and having a message_bounce > 0) is received (and not bounce). The `_routing_reset_bounce` is called to reset the message_bounce. However, prior to this fix, due to not normalizing the `email_from` contained in the `msg_dict`, well, the record having this value was never found and thus, not reset to 0. In 4935208, some of the user were unlinked for mail.discuss.channel when replying to one of the received email. opw-4935208 closes odoo#229889 X-original-commit: cf8a588 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Versions -------- - 17.0+ Steps ----- 1. Have a sale order with deliverable products & no payment terms; 2. confirm order & validate delivery; 3. create an invoice; 4. modify the delivery date; 5. save changes; 6. change product quantity of a line & confirm invoice. Issue ----- The delivery date got reset. Cause ----- The `_compute_show_delivery_date` method gets called, which triggers the recomputation of the `_compute_delivery_date` due it the latter having `line_ids.sale_line_ids.order_id` as its `depends`. Due to the way how `depends` works, if any of the fields in the record chain gets modified, the compute gets triggered. In this case, because we modified a `line_ids` record by changing the quantity, it will therefore recompute the delivery date, overwriting the custom value. Solution -------- As we only want the delivery date to be recomputed when the `effective_date` on the order changes, we should add it to the `depends` to trigger the compute in that scenario. In other scenarios, e.g. modifying the move or one of its lines, we don't want to trigger a recompute, which we can achieve by always including `delivery_date` via `_get_protected_vals` on create/write. opw-4996654 closes odoo#229888 X-original-commit: 818cf04 Signed-off-by: Steve Van Essche <svs@odoo.com> Signed-off-by: Levi Siuzdak <sile@odoo.com>
Problem Unreserve issue preventing users from validating a delivery order with 2-step delivery warehouse configuration. Introduced in the following commit: odoo@13567aa Steps to reproduce on the runbot: - Activate packages - Edit the warehouse to deliver in 2-steps - Create a product tracked by lot - Create two lots with 5 qty each - Create a sale order with 10 qty and confirm - Check the delivery order and assign: => 2 units to lot1 and create a pkg for it => 1 units to lot1 without pkg => 3 to lot2 without package - validate the delivery and create backorder - go to pick backorder and try to validate - Unreserve issue pops up - For further details check: odoo#225948 Solution: - Conditional subtracting limited to new lines only. Task ID: opw-5086289 closes odoo#229958 X-original-commit: 9cbe98b Signed-off-by: William Henrotin (whe) <whe@odoo.com> Signed-off-by: Noura El Allam (nea) <nea@odoo.com>
imanie383
force-pushed
the
18.0-i3864-rowno_imanie383
branch
from
4ce8add to
c1a26ab
Compare
Author
|
Great! Could you create the PR to odoo/odoo, please? |
imanie383
force-pushed
the
18.0-i3864-rowno_imanie383
branch
from
c1a26ab to
21f6660
Compare
Author
imanie383
force-pushed
the
18.0-i3864-rowno_imanie383
branch
3 times, most recently
from
b3231aa to
e456e38
Compare
The change resolves the static reference issue where the computeWidths function could not be patched. This limitation occurs because the `column_width_hook` declares and invokes computeWidths directly within its body (specifically in forceColumnWidths), creating a static closure at import time. As a result, dynamic overrides were prevented, reducing flexibility for extending or customizing behavior. To address this, hardcoded constants, date width computation, and the computeWidths logic were extracted from column_width_hook into a new column_widths module. This modularization enables proper patching and extension while maintaining compatibility with dependent modules.
imanie383
force-pushed
the
18.0-i3864-rowno_imanie383
branch
from
e456e38 to
322cf77
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
Description of the issue/feature this PR addresses:
The change resolves the static reference issue where the computeWidths method could not be patched. This limitation occurs because the useMagicColumnWidths hook imports and invokes computeWidths directly within its body (specifically in forceColumnWidths), creating a static closure at import time. As a result, dynamic overrides were prevented, reducing flexibility for extending or customizing behavior.
To address this, hardcoded constants, date width computation, and the computeWidths logic were extracted from column_width_hook.js into a new column_widths.js module. This modularization enables proper patching and extension while maintaining compatibility with dependent modules.
Current behavior before PR:
patches to computeWidths are ignored.
Desired behavior after PR is merged:
Enabled proper patching of computeWidths methods when needed.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr