Merge from upstream 18 20260519 01#1221
Open
royle-vietnam wants to merge 59 commits into
Open
Conversation
Steps: Create a task inside any project. Create a sub-task under that parent task. Open the sub-task and remove the project (clear the project field). Look at the status bar at the top of the form view. Issue: The status bar is displayed twice (both the Project stages and Personal stages are visible simultaneously). Cause: When the project field is cleared from a sub-task in the UI, conflicting visibility rules or residual stage data can cause the status bar widget to render twice. Fix: To resolve this, an `onchange` event is added to the `project_id` field. If the user removes the project from a sub-task, the system now instantly falls back to the parent task's project and sets `display_in_project = False`. This syncs the frontend UI with the intended backend behavior, preventing the interface from entering the broken state and removing the duplicate status bars. task-6033970 closes odoo#263849 X-original-commit: 0d9ba86 Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
* Before: the manufactured quantity on product use the planned quantity * After: Use actual produced quantity closes odoo#263536 X-original-commit: 50def96 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
…e types
Pre-requisite:
---------------------------------------
1. Install the Time Off module
2. Create a new company (e.g, Test Company)
3. Create New Timeoff Type:
* Ensure a default company is set (e.g, YourCompany)
4. Duplicate the created Time off type:
* Remove (Copy) from the name so both records share the same name
* Clear the Company field on the duplicated record
Steps to reproduce:
---------------------------------------
1. Go to Time Off type which has no Company
2. Allocation Smart button > New
3. Set allocation for some days (e. g, 10 Days) > Approve allocation
4. Now, click on Employee > Time Off smart button
5. On the Dashboard, you can see allocated leaves
6. Click on any day to create a Time Off Request
Observation:
---------------------------------------
The allocated Time Off Type is not available in the request wizard,
even though allocation exists.
Issue:
---------------------------------------
When natively computing allocation statistics for the UI, the `_compute_leaves`
loops through a pre-fetched `data_days` structure and incorrectly extracts the
calculation metrics by matching the `holiday_status.name` string via a list
comprehension lookup index (`item[0]`).
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/hr_holidays/models/hr_leave_type.py#L288-L294
If Time Off Type A and Time Off Type B share the name 'Generic Leave', the list
comprehension evaluates sequentially and forcefully maps the dictionary of
whichever version structurally sits first in the memory sequence directly
onto both overlapping identifiers simultaneously!
Solution:
---------------------------------------
Directly match records using their unique ID.
This ensures that each database record always retrieves its own correct data,
preventing any mix-up or accidental sharing of values between records that may
have the same name.
opw-6105759
closes odoo#261680
Signed-off-by: Mélanie Peyrat (mepe) <mepe@odoo.com>
The currency rate was previously computed using the first invoice line, regardless of its type. This caused incorrect rate calculation when the first line was not a product line (e.g., section, note, or display-only lines). This fix filters invoice_line_ids to use the first actual product line when extracting amount_currency and balance, ensuring that the derived rate reflects a valid monetary line. opw-5208724 closes odoo#239920 X-original-commit: fe8fa8d Signed-off-by: Ali Alfie (alal) <alal@odoo.com>
Issue: --- Steps to reproduce: 1- Create a `Discount Code` program. 2- In SO, use `Coupon Code` wizard and use the code. 3- After available rewards are shown, discard the wizard. 4- Re-apply the code. Validation Error: The promo code is already applied. As the reward is not applied, this is functionally confusing. At this point We can see the reward only inside the rewards wizard view. If we allow re-apply the code in case no reward line is created for the `rule.program_id`, we can still see the reward by re-applying the same code, without any side effects. opw-6164198 closes odoo#263898 X-original-commit: 86372a4 Signed-off-by: Mohammadmahdi Alijani (malj) <malj@odoo.com>
Issue: When creating a payment with an early payment discount, on an invoice using a cash rounding with a strategy of “Modify tax amount”, the early payment discount lines on the payment journal entry will be far off from the correct amount Steps to reproduce: 1. Create a sales tax for 8.1% 2. Create a cash rounding record for 0.05 as the rounding precision, “Modify tax amount” as the rounding strategy, and “Nearest” as the rounding method 3. Create a payment term with early payment discount of 2% if paid within 18 days. And reduced tax on early payment. With a due term of 100% 30 days after the invoice date 4. Create an invoice on 1/1 with a subtotal of 339.60 and the tax of 8.1% and add the cash rounding method and payment term created earlier 5. Create a payment for it 9 days later on 1/10 for the full amount after the early payment discount is applied Cause: tax_amounts is grabbing the amount for a certain tax from the last line on the invoice with the same tax_repartition_line_id. Usually there is only one tax line representing a certain tax on an invoice. However, when a cash rounding is applied to the invoice with a strategy of “Modify tax amount”, the cash rounding line that is created will also have the same tax_repartition_line_id. In that case, it will grab the amount on the cash rounding line instead of adding the first tax amount with the cash rounding line amount Solution: In tax_amounts, add to the accumulating value if a tax_repartition_line_id already exists as a key, otherwise insert it into tax_amounts opw-5998497 closes odoo#259025 Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
__ When printing delivery slips, the description of kit components isn't shown. Therefore, we only see the components on the slip, and not the kit they come from. 1. Go to settings. Under Inventory, in the Operations section, enable Packages. 2. Go to Sales and create a new quotation. Select a customer and add a kit product. Click on confirm. 3. Click on the Delivery smart button. Click on Put in Pack and Validate. 4. Click on the small cog > Print > Delivery Slip. The kit from which the components belong should be indicated somewhere on the slip. The kit isn't indicated. When we print a delivery slip without putting in pack, we can see on the slip that the first line, in bold, corresponds to the kit name. However, after putting in pack, the first line, in bold, indicates the Package id: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L116 Thus, the lines after will correspond to the components, of which we retrieve the details with: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L125 However, in `_get_aggregated_product_quantities`, we set the description of the components to an empty string under that case: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/mrp/models/stock_move.py#L180 leaving us with no description for the components, and therefore not indicating the kit to which they belong. __ opw-6006514 closes odoo#254200 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When running the test, `button_validate()` was called twice in succession. - Once explicitly - Once through `process_cancel_backorder()` The first time it is called though, it's not through the restricted user that we want to test, allowing some access rights checks to run smoothly. The second time it's called with the restricted user, the cache still contains some data that should be no longer accessible, allowing the test to run even though it shouldn't. closes odoo#264057 Related: odoo/enterprise#117047 Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to Reproduce : Go to To-Do → Create New and add a Table of Content block Type text → in new line create /h1 → it appears in ToC Place cursor before /h1 and press Backspace → it merges with paragraph Issue: Table of Content block does not update accordingly Cause: After the heading is merged with the previous paragraph, `delayedUpdateTableOfContents` is triggered, but at that time no heading is available in the editable area. As a result, instead of updating the Table of Contents, it returns without making any changes. Solution: If Table of content already contains heading, then update regardless of whether editable contains heading elements or not. task-6150579 closes odoo#261675 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, creating an invoice with an Early Payment Discount (EPD) as a payment term could cause the schematron validation of the generated invoice to fail when an invoice line had a 0% tax. The issue was caused by generating two TaxSubtotal nodes for the same TaxCategory (0%, exemption code 'E'): - one for the 0% VAT - one for the EPD discount applied to the total amount However, Peppol requires a single VAT breakdown (TaxSubtotal) per VAT category (in this case: E) Additionally, when VAT was set to 0%, the allowance charge TaxSubtotal incorrectly used 'S' as a hardcoded tax category code. Another issue (rare, but could happen) is that we group the epd taxes only by percent. If we have 2 tax details with the same percent but different tax category, we would substract the the combined (for both tax categories) EPD amount from both. This commit fixes the 3 issues. task-5900496 closes odoo#263501 X-original-commit: 949c727 Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
- Attendance checkout
- Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
- Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
- Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.
- Planning access error
- Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
- Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
- Solution: using sudo method for recompute.
closes odoo#264053
Task: 6131692
X-original-commit: 4218e3b
Signed-off-by: Krzysztof Magusiak (krma) <krma@odoo.com>
Signed-off-by: Olivier Renson (renol) <renol@odoo.com>
runbot-243298 closes odoo#262804 Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install membership module - Create a cash rounding with the 'biggest tax' strategy and 0.05 rounding - Enable customer addresses and create a partner P with an invoice address I - Create an invoice, select I as customer (P will be assigned as delivery address but this is not relevant) - Add an invoice line for 100.03 and any tax and apply the cash rounding - Confirm -> MissingError: record has been deleted Cause: - When creating the cash rounding lines, we set the `partner_id` from the invoice's partner (in our case partner I, which has P as `commercial_partner_id`). - When posting the invoice we look for lines that have partner id different than the invoice's commercial partner id and we call the write method to set the commercial partner id instead https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239 - In some cases, for example in the `membership` module, the override of the write method calls the super() before using `self`. https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49 But the super triggers the `_sync_tax_lines` mechanism, during which the rounding line in deleted https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110 https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114 Therefore `self` doesn't exist anymore when comming back in the override Fix: Setting the commercial partner on the rounding line to avoid calling the write method opw-6128868 closes odoo#262759 Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
**Before this commit** If a gift card balance fully covers a shopping cart containing multiple events, Odoo auto-confirms the order as soon as the last event is added, skipping the final checkout step. **After this commit** Sale orders will no longer be automatically confirmed when a customer registers for a paid event, even if an applied gift card brings the total balance to zero. opw-5896626 closes odoo#246629 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field. Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods. All measures are performed with a warmed up cache Benchmark: # of am | Before | After 38982635 | ~17s | ~22ms closes odoo#264211 X-original-commit: 4376480 Signed-off-by: David Monnom (moda) <moda@odoo.com> Signed-off-by: fja-odoo <fja@odoo.com>
SQL `IN %s` clause failed due to an empty tuple by causing a syntax error. By switching to `read_group`, the ORM handles empty domains gracefully. This also improves maintainability by using standard API methods instead of direct cursor execution. opw-6196166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr closes odoo#264140 X-original-commit: 6403154 Signed-off-by: Arnaud Joset (arj) <arj@odoo.com> Signed-off-by: Ezzuldin Zaky (ezza) <ezza@odoo.com>
If `git ls-remote origin <db_branch>` randomly fails, we assumed `db_branch` was `master`. It was useful for devs in the past, but now lead to update to Trixie on IoT Boxes 25_07 and previous, which is unwanted in such circumstances. We now skip upgrade if `db_branch` is `master`. closes odoo#264188 X-original-commit: 01637cd Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com> Signed-off-by: Louis Travaux (lotr) <lotr@odoo.com>
This commit removes unecessary whitespace when reading qweb attributes. This result in nicer HTML output. opw-6173086
**Issue:** Test won't fail after [1] due to the added `[TEST]`. **Fix:** Add it to the expected subject. [1] odoo@4ef8b7c opw-6168632 closes odoo#264035 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Drop "s_cta_mockups" or "s_closer_look" snippet. 3. Click on any image that has a shape. Issue: The color picker option is missing for images with shapes in these snippets. Reason: These snippet templates do not include the "shapeColors" dataset on the image elements. task-5880905 closes odoo#246249 Related: odoo/design-themes#1274 Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 closes odoo#264069 X-original-commit: 669b9b8 Related: odoo/enterprise#117055 Signed-off-by: Lou Habert (loha) <loha@odoo.com> Signed-off-by: Junqi Wu (juwu) <juwu@odoo.com>
**Problem:** account move created by stock valuation layer does not take analytic account from PO **Steps to reproduce:** - make sure you have at least one analytic account - create a storable product with categ standard automated - set a positive cost - create a PO for 1 quantity - on the PO line of the product, in the analytic distribution column (might need to be unfiltered) set an analytic account - confirm PO and validate receipt - click on the valuation smart button and on the book widget of the stock valuation layer **Current behavior:** the account move lines have no analytic distribution **Expected behavior:** The account move lines should inherit the analytic account from the purchase order line like it's the case for the bill. For the analytic distribution of the Bill, the selection is : 1) take analytic distribution from PO if one 2) if not, take from distribution model if there is one 3) empty Currently for the account move lines of the svl the selection is: 1) take from distribution model if there is one 2) empty But we should use same selection as for the bill **Cause of the issue:** When setting the analytic distribution we first try to use the one from PO/SO by calling _related_analytic_distribution() https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/account/models/account_move_line.py#L1157 But since the account move lines have no purchase_line_id no analytic distribution will be returned https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/purchase/models/account_invoice.py#L540-L545 opw-6022695 closes odoo#263236 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, when making a payment on a Stripe terminal, the only way to cancel the payment was from the POS interface. In the self order kiosk, it was impossible to cancel the payment. After this commit, a cancel button will appear on the payment terminal for both POS and kiosk Stripe payments. task-6166789 closes odoo#264270 Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. closes odoo#264328 Signed-off-by: Raphael Collet <rco@odoo.com>
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, added an api.constrains to prevent an ir.attachment from having itself as a res_id. opw-6206075 closes odoo#263591 Signed-off-by: Joe Wesnofske (jowes) <jowes@odoo.com>
If a product uses an archived UOM and an order is then created in the POS with this product, an error would occur because it could result in trying to use a UOM that wasn't loaded in the POS since it was archived. To fix this issue, we now load archived UOMs in the POS. --- closes odoo#263838 Task: https://www.odoo.com/odoo/project/1737/tasks/6197465 Signed-off-by: David Monnom (moda) <moda@odoo.com>
Steps to reproduce
-----
- Modules: Sale, Purchase, Mrp, Accounting
- Enable automatic accounting & anglo-saxon valuation
- Create an AVCO Product category (AVCO automatic valuation)
- Create a Kit product storable & AVCO
- Kit bom
- Comp as a component (storable & AVCO)
- Settings > Decimal Accuracy > Product Price > set to 4 digits
- Purchase 3 units of Comp at 3.3333 piece & validate reception
- Make 2 sales for 1 unit of Comp each & validate both delvieries
- Create a SO for 1 Kit and 1 Comp & confirm
- Create & confirm invoice
- Go to the delivery, force quantity on the component and try to validate
delivery
> Error message: "You are trying to reconcile some entries that are already
reconciled."
/!\ Fun(?) fact: this error doesn't occur if the order of the moves is inverted.
Cause
-----
When the purchase delivery is validated, a stock valuation layer is created for
3 units with a value of 10. As they are sold individually, these 3 units
generate a valuation layer for 3.33 per unit summing to 9.99.
When we validate the last delivery, the 0.01 difference is detected and an
adjustment is made on the valuation layer in `_prepare_out_svl_vals`.
However this adjustment is made for the product when the invoice line concerns
the kit. As a result, the first reconciliation fails and the line is added to
the list to be reconciled later.
Then, when handling the line for COMP2, it will successfully reconcile the lines
while it is still in the pool to be reconciled, resulting in an error when
attempting to reconcile it later.
This is caused by `_stock_account_anglo_saxon_reconcile_valuation` where the
`product_stock_moves` only contains the kit move when called with the kit
product as argument, but it contains both moves when called with the component
itself as argument. This leads to the same AML being reconciled twice.
https://github.com/odoo/odoo/blob/f0b9f4c234cd0101f5cb259e58620e1cf65bb2b7/addons/stock_account/models/account_move.py#L222-L225
-----
Ticket:
opw-5722072
closes odoo#263418
X-original-commit: 9a39b5f
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: David Van Droogenbroeck (drod) <drod@odoo.com>
l10n_it_edi calls self.env['account.edi.common'] for partner and bank account import, but does not declare account_edi_ubl_cii as a dependency. The FatturaPA import crashes with KeyError when the module is absent. Copy _import_partner and _import_partner_bank from account.edi.common into AccountMove as _l10n_it_edi_import_partner and _l10n_it_edi_import_partner_bank. The helpers rely on res.partner._retrieve_partner and _run_vat_test from account, and res.partner.bank._find_or_create_bank_account from base, all already reachable through the existing depends chain. The two calls landed in PR odoo#254505 (commit 63926d9). closes odoo#264326 Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
SwiftKey keyboard Problem: When using the Microsoft SwiftKey keyboard, placing the caret at the beginning of a table cell and triggering a `beforeinput` event can result in `getSelection()` returning an incorrect selection. Notably, the selection immediately before the event is correct, but it changes unexpectedly without firing a `selection_change` event. Solution: Cache the selection whenever a `selection_change` event fires, ensuring we keep the last correct selection set by the user or editor. Steps to reproduce: - Edit a table with an empty cell. - Place the caret inside the empty cell. - Press Backspace. - Observe that the focus moves to the previous cell unexpectedly. task-6150731 closes odoo#259798 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The `_gc_session_sequences` method searches for sequences using Odoo's `=like` operator, which maps to SQL LIKE where `_` is a single-character wildcard. The prefix `pos.order_` (added by `pos_self_order`) therefore matched the `pos.order.line` sequence, which has no integer suffix and was never added to `keep_codes`, causing the autovacuum to delete it silently. This made POS unusable until the sequence was recreated manually. Fix by filtering the search results with `str.startswith` to retain only sequences whose code literally begins with the prefix, discarding any false positives introduced by the SQL wildcard. opw-6215331 closes odoo#264322 Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Steps to reproduce:
- Open POS Restaurant
- Add a General Note
- Remove the General Note
- The message badge on “Send to Kitchen” remains visible
Issue:
Removing a General Note set `general_note` to `undefined`, which was
detected as a change and kept the badge visible.
Fix:
Normalize empty General Notes to an empty string ("") so removing a note
restores the correct initial state.
Task-6101501
Related PR: odoo/enterprise#113514
closes odoo#258632
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Backport of 7c68c3d including its fix: e490c0c Issues: Cancelling the move dest of a manufacturing order does not cancel the MO nor log's an activity warning for the responsible to update the manufacturing demand manually. Additionally, when selling MTO manufactured products, cancelling the delivery and then changing the sol's demand will update the MO for an incorrect amount. Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO route - Create an MTO product with BOM - Create and confirm an SO for 3 units of that product - Cancel the delivery of 3 units > There is no notification on the unrelevant MO linked to the SO - Adapt the quantity of the SOL from 3 to 0 > The delivery is cancelled but no activity is logged what's so ever Expected behavior: Both of these operations should log an activity as the demand of the MO is not updated on quantity decrease. opw-6010109 opw-6105366 opw-6100043 opw-6087909 closes odoo#258093 X-original-commit: 796316c Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Issue: property_delivery_carrier_id on res.partner can hold an archived delivery.carrier record. Meaning that we pass an archived record to the context and that we can select the archievd delivery.carrier in the choose.delivery.carrier wizard. Solution: Only pass active records through the context opw-6125792 closes odoo#264324 X-original-commit: e2de7a5 Signed-off-by: Eliott Loop (oplo) <oplo@odoo.com>
FatturaPA carries DataScadenzaPagamento and CodicePagamento on issued invoices and customer credit notes too. The import skipped both reads for out_invoice and in_refund, so invoice_date_due fell back to today() and payment_reference stayed empty on those documents. Move the due date and payment_reference reads outside the incoming-only guard. Bank account creation stays incoming-only. closes odoo#264573 Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
The delivery transfer for a product tracked by serial number is not
linked to the POS order when there is no available stock.
When validating a POS delivery in real time, stock can split the transfer
into a completed picking and a backorder (e.g. one line fully delivered
with lots, another serial-tracked line with no stock and no serial
number).
Steps to reproduce:
-------------------
* Setup two products: one tracked by qunatity with some quantity on-hand
an other tracked by SN but no quantity on-hand
* Open Pos
* Sell in one order, both products without providing SN
* Validate payment
* Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders
> Observation:
The first picking shows the POS order as Source Document but
the backorder has no source document and is not linked to the POS
order.
Why the fix:
------------
Pos Origin (Source Document, POS order, session) was only written
on the pickings returned by `_create_picking_from_pos_order_lines`,
which did not include pickings created during `_action_done()`. Extend
the write to the initial pickings and their backorders so every
transfer stays tied to the originating `pos.order`.
opw-6090606
closes odoo#259370
Signed-off-by: Stéphane Vanmeerhaeghe (stva) <stva@odoo.com>
We're adding new PO files for the following languages: lo
We're adding new PO files for the following languages: pl
This commit fixes two issues with upgrading from old IoT box images to 19.1+ DBs: - The IoT box would try and start checking out with git at the same time as the upgrade script rebooted the system. This would leave the git branch as the DB version (e.g. 19.2) but with the files still being at 19.1. To fix this, we sleep after the script until we reboot. - On reboot, the IoT box would then git checkout to the new version anyways. However, it would not install apt packages, leaving the Odoo service unable to start because of a missing 'geoip2' package. To fix this, we simply include this package in the upgrade script. task-6217972 closes odoo#264778 X-original-commit: b89d715 Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com> Signed-off-by: Max Whale (mawh) <mawh@odoo.com>
Customers placing an order without logging in and with the "Pick up in
store" delivery method are not notified when the delivery is confirmed
1. Install eCommerce and Sales
2. Go to Settings > Website > Delivery and enable "Click & Collect"
3. Go to Settings > Inventory > Shipping and enable "Email Confirmation"
4. Go to Website > Configuration > Payment Providers and Install Demo
5. Go to Website > Configuration > Delivery Methods and open "Pick up in
store", set YourCompany as warehouse and publish it
6. Go to Sales > Products, open product "Office Lamp", click on "Update
Quantity" in the status bar and add 5 units
7. Log out
8. Go to the shop, add product "Office Lamp" to the cart and checkout
9. Fill in the address form and continue checkout
10. Select "Pick up in store" as delivery method and select a location
11. Confirm the order and pay with Demo
12. As user Mitchell Admin, go to Sales, remove the default filter and
open the newly created sale order
13. Open the related delivery with the smart button and validate it
14. No delivery order confirmation was sent to the customer (check
emails)
Issue:
Confirming an order with a "Pick up in store" delivery method replaces
the `partner_shipping_id` of the sale order with an archived partner
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/delivery/models/sale_order.py#L178-L192
which updates the `partner_id` of the related `stock.picking` with the
archived partner
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/sale_stock/models/sale_order.py#L130-L132
This will unsubscribe the old `partner_id` on the `stock.picking` and
try to subscribe the archived partner
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/stock/models/stock_picking.py#L1120-L1125
Because the partner we want to subscribe is archived, he will be
filtered out and the subscribe action will have no effect, preventing
him from receiving the delivery confirmation
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/mail/models/mail_thread.py#L4367-L4369
Solution:
Subscribe the parent of the archived partner when we write a
`partner_id` on pickings with "in_store" `delivery_type`. This ensures
the unarchived partner is subscribed to the picking allowing him to
receive the mail confirmation.
opw-6095396
closes odoo#263005
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
This commit will add the possibility to do an adjustment on the line 25. Useful when you start using Odoo but have a VAT credit carried forward from the previous month (which should appear in box 25 of your return). task-6072474 closes odoo#264067 X-original-commit: 9b9759f Signed-off-by: Florian Gilbert (flg) <flg@odoo.com> Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
The previous commit fixes a behavior that is expected when the user makes a selection that starts in any element and ends in a table cell (the whole table gets selected), but the reverse case was never handled, namely when the selection starts in a table cell and ends outside of it. backport-odoo@68e71fa task-5420366 closes odoo#264722 Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, for DBs with a very large amount of products it was possible for the thread to run out of memory when importing an invoice or a bill. The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread. The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem. Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import. opw-6168737 closes odoo#264343 X-original-commit: 878c08c Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com> Signed-off-by: Victorien Sonneville (viso) <viso@odoo.com>
…equal Steps to produce: - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to shop page and search for the product. Issue: - The strikethrough appears on the compare price (25) even when the compare price equals the sales price. - The strikethrough should only appear when the compare price is strictly greater than the sales price. Root cause: - In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal. Solution: - Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2]. [1]: https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834 [2]: https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346 opw-6178129 closes odoo#264891 X-original-commit: 6a6902b Signed-off-by: Krishna Arvindkumar Patel (krip) <krip@odoo.com>
When renaming a custom field that is inherited, first remove the generated inherited fields from the database. backport of odoo#240603 opw-6148175 closes odoo#264044 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit will add a new props to ColorSelector to disable default theme colors to allows studio to not use them opw-6167143 linked to odoo/enterprise#109206 closes odoo#264917 Related: odoo/enterprise#117555 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
…osition Backport of odoo#263872 OPW-6022540 closes odoo#264603 Signed-off-by: William André (wan) <wan@odoo.com>
…ccount When a cash basis tax is configured with a payable/receivable transition account, tax journal items are generated on that account without a due date. Since payable/receivable accounts require a due date on journal items, this leads to the validation error during move creation. This commit adds a preventive validation to disallow configuring payable/receivable accounts as cash basis transition accounts, avoiding inconsistent accounting configurations and runtime errors. opw-6189615 closes odoo#264720 X-original-commit: c85e18a Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com> Signed-off-by: Krunal Gelot (krge) <krge@odoo.com>
Currently, an incorrect VAT format is used in the generated FA3 XML for non-Polish partners, where the VAT number includes the country code. Steps to reproduce: - Install the `l10n_pl_edi` module and switch to a PL Company. - Go to Settings and enable `Allow KSeF integration` (refer to [1]). - Create and confirm an invoice for a customer (e.g., Azure Interior). - Send the invoice using `by KSeF (e-Faktura)`. Observation: In the generated XML file, the `NrID` field contains the VAT number with the country code for non-Polish partners. Root Cause: At [2], `get_vat_number` sets the VAT number using `compact` from `stdnum.pl.nip`, which only works for Polish VAT numbers. At [3], `get_vat_number` correctly formats Polish VAT numbers without the country code in the `if condition`. However, in the fallback (else) case, it returns the VAT number as it is, including the country code. Fix: This commit ensures that for non-Polish VAT numbers, the country code is removed before setting the `NrID` or `NrVatUE` values in the XML, aligning the format with KSeF requirements. [1]: https://www.odoo.com/mail/message/1057847327 [2]: https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257 [3]: https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82 opw-6120118 closes odoo#263081 Signed-off-by: John Laterre (jol) <jol@odoo.com>
Issue before this commit: In the Italian Annual VAT Report, the balance (base amount) for line VF25 displays incorrect values. Instead of computing the sum of the taxable bases for the passive operations, the report erroneously mixes tax amounts into the balance column. Steps to reproduce the issue: 1. Download Accounting and l10n_it 2. Go to Tax Report and visualize the Annual Tax Report (IT) 3. Go to VF VAT Report 4. See the VF25 is mixing taxes and balances Cause of the issue: The root cause lies in the aggregation_formula definition for the tax_annual_report_line_VF25 record. The formula was incorrectly configured to aggregate the .tax expressions for lines VF1 to VF13 (VF1.tax + VF2.tax + ...) instead of their respective .balance expressions, while correctly using .balance for the remaining lines (VF17 to VF24). https://github.com/odoo/odoo/blob/878c08cf522a3278b4e6ff5f3d18444989e9998d/addons/l10n_it/data/tax_report/annual_report_sections/vf.xml#L286-L299 It's just a typo in this commit: odoo@f292ba1 Reason to introduce the fix: From documentation https://www.agenziaentrate.gov.it/portale/documents/20143/9602686/IVA_ANNUALE_2026_istr.pdf/2a42fb92-1b76-229a-d0f5-06069d79b514?t=1768504755711 : Rigo VF25, colonna 1, va indicato il totale degli imponibili determinato sommando gli importi riportati ai righi da VF1 a VF23, colonna 1, diminuito dell’importo di cui al rigo VF24. In colonna 2 va indicato il totale delle imposte determinato sommando gli importi delle colonne 2 dei righi da VF1 a VF13. opw-6172791 closes odoo#264764 X-original-commit: feb1a4e Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com> Signed-off-by: Ester Andreetto (esand) <esand@odoo.com>
|
@royle-vietnam Viindoo Test Suite has failed! |
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:
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