Syncing from upstream odoo/odoo (tmp.17.0) #33471
Merged
Conversation
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
This commit updates the legacy dhl connector module title and description in the base POT file. Task-3759205 closes #211228 X-original-commit: df207a8 Related: odoo/enterprise#86208 Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com> Signed-off-by: Mohammad Abdulmoneim (abdu) <abdu@odoo.com>
Steps to Reproduce: 1) Create an Accrual - Set carryover_date to other - Set carryover_month to April. - Set carryover_day to Last Day. 2) Add an Accrual Rule to the accrual. 3) Create a Leave Allocation - Set allocation_type to Accrual. - Assign the Employee. - Define the Validity Period (date_from, date_to). Issue: On accrual creation when the user selects the "last day" option for carryover_day, we are currently assigning the 31st as the day Hardcoding the 31st as the `carryover_day` can lead to errors when the `_get_carryover_date` method is triggered. For example, this causes failures in months with fewer days (e.g., February or April). Fix: evaluate the correct carryover_day based on the selected month & year when the value is set to last day, before using it to prepare the final date. This ensures that the last day of each month is accurately determined and applied. closes #211205 Opw: 4792938 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Accessing external resources in chrome can increase randomness in execution for multiple reasons: - the external resource may temporary not be available - the external resource may be faster-slower to load - the external server could block some requests because of rate limiting - the network may be unreachable. Moreover, downloading fonts at every execution also slows down the tests A possibility to solve the issue was to block the network on runbot, in the dockers. The main problem with this solution is that it wouldn't be the same behavior locally. It is also hard to adapt all versions at the same time. This commit introduced another solution, using Fetch.enable in the chrome developers tools. This will allow to have a callback on every external request, allowing to enable/disable/give an alternate answer to the request. All local request are allowed, all external request should be either blocked or an alternative answer given. This could be costly but at first glance it looks like it had no visible negative impact on performances. The first version was blocking all external requests, leading to a lot of failing tests, most of them already seen in nighties. Following this attempts a fix was to vendor all needed sources leading to ~130 cached url, with more than 100 fonts. This list was furthered reduced to have default fonts that would be returned reducing the load. A test was made to return a 404 instead and it was actually enough, and it is the same for most requests (stripe, ayden, ...). Only a few of them needs a answer close to reality. - The gooleapis css can be emty but not a 404 because it may make some of the css computation fail (website.backend_assets_all_wysiwyg.min.css) One of the failling test is TestCustomSnippet.test_01_run_tour This final version returns a 404 for most resources. A version returning 500 also works fine. This pr could impact other cis (odoosh, other runbot) but the impact is expected to be slow wince only two tests needed to be adapted outside tests/common.py. It would be still possible to make Fetch.enable optional using an environment variable. Targeting 18.0 looks reasonable for a start, could be backported to 16.0 later closes #210880 X-original-commit: f866cb0 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce: - Create a SO from sales, and don't confirm it - Enable 'Allow Ship Later' in PoS - From PoS, settle the SO, with "Ship Later" option Observed behavior: From the inventory app -> Delivery orders, we can see that 2 pickings for this order have been created, one for the original SO order, and another one for the PoS order. Both of them are in state 'confirmed', i.e. "Ready". Expected behavior: The original SO picking should have been cancelled, i.e. in state 'cancel', and only the PoS picking should be "Ready". Why that happens: When settling the SO from PoS, that will create a new order from PoS with its associated PoS picking. While doing that, we also confirm the original SO [1], changing its state from 'draft' to 'sale', and that will create a move and a picknig associated with that SO, both in state 'confirmed'. So at this point, we're heading toward having 2 pickings, one from the PoS order and the other from the SO, both in state 'confirmed', which is undesired! What we want is having the SO's picking in state 'cancel', and the picking from PoS in state 'confirmed' (since we have settled the order from PoS). To achieve this behavior, we check if the quantity delivered on the SO (i.e. `so_line.qty_delivered`) compensates for the qty that should be deliverd, i.e. for `so_line.product_uom_qty` [2], and if so, we cancel the SO picking ([3], [4]). However, if the order is "ship later", the `so_line.qty_delivered` will be 0 at first, and will only get updated when the picking has indeed being shipped [5], resulting in `new_qty` always being a positive number, and hence also the `product_uom_qty` on the SO pikcing [6], meanign that the SO picking will not qualify to be cancelled. The fix: Now, in the computation of `new_qty`, we don't only compare `so_line.product_uom_qty` with what quantity has indeed been delivered (i.e. `so_line.qty_delivered`), but also with the quantity that is expected to be delivered later (i.e. `get_expected_qty_to_ship_later`). [1]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L74 [2]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L88 [3]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L95 [4]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L103-L104 [5]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/sale_order.py#L57 [6]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L94 opw-4375941 opw-4457592 opw-4490398 closes #197031 Signed-off-by: David Monnom (moda) <moda@odoo.com>
Odoo part of the IAP PR. Add some more error codes that will be sent by the IAP server, in order to provide more useful errors for the users. closes #209410 Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
Previously the `state name` of partner is validating, but as per government API json schema `state tin number` is required. After this commit: - The validation now checks the state tin number instead of the state name, ensuring it is a valid and min 1 and max-2 digit number. closes #211276 X-original-commit: 0f7b87c Signed-off-by: Josse Colpaert (jco) <jco@odoo.com> Signed-off-by: Prem Patel (prep) <prep@odoo.com>
Before fix, when a user manually added a narration (e.g. terms and conditions) on an invoice, changing the journal or other dependent fields would trigger a recompute of the narration field, which cleared the user-provided content. Steps to reproduce: ---- 1. Create a customer invoice. 2. Add custom narration (terms and conditions). 3. Change the journal. → The narration field is reset and the manually-entered content is lost. After this commit: ---- The compute method for the narration field checks if narration already exists and preserves it, preventing loss of user input. ---- opw-4757119 closes #211438 X-original-commit: ef67e84 Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com> Signed-off-by: Smit Patel (pasm) <pasm@odoo.com>
issue when you change an odoo event organizer the original gets archived and a new one is created this behavior should only be happening with microsoft synced events steps to reproduce: - install microsoft_calendar - create new event - change organizer and save the event is archived opw-4765254 closes #210100 Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Upgrading from 16 to 17 causes issues with demo data. It happens when the main company has no chart template, because it won't find the correct account.journal for the moves (and account.account for the lines). To reproduce: 1. Initialize an Odoo 16.0 database with account_accountant and NO demo data. (There will be no country_id set on the default company, so the post_install hook in account won't install l10n_generic_coa) 2. Install demo data (the post_install hook in account is then not fired, still no l10n_generic_coa) 3. Upgrade to Odoo 17.0 By creating the demo data in Python instead of the XML, we can put the condition to avoid creating the move if we do not have a chart template on the company. In community, we filter on draft moves before posting them opw-4781045 closes #200420 Related: odoo/enterprise#80812 Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
After this commit: - A Print button allows users to generate the E-Waybill or Challan PDF. - The PDF is attached to the chatter and gets downloaded. - Applies only when the document is marked as an E-Waybill or Challan. Task-4807694 closes #210998 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
When trying to send a vendor bill that uses a tax with l10n_es_type 'sujeto_agricultura' with ticketbai using the agency bizkaia, we are faced with an error code. This is due to the amount of these taxes being different than what is allowed (10.5% and 12%). The two 'sujeto_agricultura' taxes are actually part of a special regime and should be exempted when sent [see this article for reference](https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca.html) This PR adapts the data sent to bizkaia, in a similar manner as #196017 did for SII, by setting `ClaveRegimenIvaOpTrascendencia` to `02` and `TipoFactura` to `06` if we have a 'sujeto_agricultura' tax. [reference](https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/Validaciones_ErroresSII_v1.1.pdf) opw-4781267 closes #211065 X-original-commit: b81bc58 Signed-off-by: Ruben Gomes (rugo) <rugo@odoo.com> Signed-off-by: Florent Huylenbroeck (flhu) <flhu@odoo.com>
Issue --- Previously, printing a survey with access mode set to "invited people only" required an existing `survey.user_input` record. Without it, the print route failed silently and redirected to the homepage. FIX --- This commit allows surveys to be printed without answers. It introduces an option to bypass the "token_required" validity check by allowing `ensure_token='survey_only'`. This skips token validation specifically for the print route, while preserving it for the start route. Reproduce --- - -i survey - create new Survey, with "Access Mode": "invited people only" - click "Print" BUG -> taken to the odoo main page, instead of empty printed survey opw-4292331 closes #189738 Signed-off-by: Florian Charlier (flch) <flch@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.
bt_gitbot