Syncing from upstream odoo/odoo (staging.17.0) #34227
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
Steps to Reproduce: - Set the Odoo backend language to Spanish. - Enter edit mode. - Drag and drop the "Text-Image" snippet. - Click on the image within the dropped snippet. Bug: The "Layout" menu in the sidebar overflows, causing a horizontal scrollbar. Issue: The width of the `we-button` elements within the `we-button-group` was not handled correctly. In the Spanish translation, the text in the "Layout" options was too long, resulting in overflow and a horizontal scrollbar in the sidebar. Solution: This commit addresses the layout issue specifically for DOM structure involving `we-button-group` and `we-select`. Without affecting other styles, it applies a grid template to equally divide the available space among the buttons, preventing overflow. task-4378522 closes #217722 X-original-commit: 23d8df6 Signed-off-by: Benjamin Vray (bvr) <[email protected]>
PR#135607 breaks support of image types other than `png` for menu icons. This puts back the support for previously supported image types. closes #218131 Signed-off-by: Martin Trigaux (mat) <[email protected]>
…d_date` in FacturX XML Issue: The FacturX XML has a fiel `BillingSpecifiedPeriod`, it should depend on `deferred_start_date` and `deferred_end_date` if they are there. Currently it only outputs the invoice date as start date and the due date as end date. Steps to reproduce: - Install "l10n_de" and switch to a German company - Go to a contact, in the page Accounting > Electronic Invoicing change the format to "Factur-X (CII)" - Create an invoice for this contact - Add a start date and end date on the line of this invoice (`deferred_start/end_date`) - Confirm and send to Factur-X - In the generated XML the dates used are the invoice date and the due date Cause: As the `deferred_start_date` and `deferred_end_date` fields are defined in enterprise and the XML generation is in community, this [commit](f0c5d5b) set dates defined in comunity instead of the deferred ones. Solution: Mimicking [the way it's done for UBL20](https://github.com/odoo/odoo/blob/638268a81ed5a292a02d7fc353c4954159de54e1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L846) we check if `deferred_start_date` and `deferred_end_date` are defined (i.e. account_accountant is installed). If it's the case we use the min/max of the `deferred_start_date` and `deferred_end_date` as start/end date of the `BillingSpecifiedPeriod` in the XML. To include as much info as we can this commit also adds the `deferred_start_date` and `deferred_end_date` on lines. opw-4874370 closes #215595 Signed-off-by: Claire Bretton (clbr) <[email protected]>
The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. - Behavior prior to this PR: In the DIOT, the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% are sums of taxes paid with this type of tax. And all the tax columns are based in the base not in the tax part. - Behavior after this PR. Taxes now have a correction in their tags so that the columns in the DIOT report are calculated correctly, Tax columns only contains tax values, not base values. opw-4920577 "I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr" closes #217441 Related: odoo/enterprise#89481 Signed-off-by: Antoine Dupuis (andu) <[email protected]>
Before this commit, if multiple documents were sent to print at exactly the same time, some of them could end up erroring because the Windows printing API requires us to send one document at a time. After this commit, we use a lock similar to the Linux driver, to ensure that only one document is sent to the printer at once. opw-4829908 closes #218300 Related: odoo/enterprise#89930 Signed-off-by: Max Whale (mawh) <[email protected]>
## Short functional explanation of the error When printing a reception report containing a lot of products, the top row of the pages after the first one is overlapped with its corresponding header in the resulting PDF. ## Reproduction Steps 1. Open the settings. In the inventory section, enable "Reception Report". 2. Create a new quotation and add at least 40 different products. Each product should have at least 1 copy in stock, and the quantity to order must be greater than the quantity we have of this product in stock. 3. Confirm the sales order. 4. Create a new purchase order and add the exact same products you added in the quotation. 5. Confirm the order and click on the "Recept" smart button. 6. Click on the "Allocation" smart button and click on the "Assign all" gray button. 7. Click on print and open the PDF once it finishes downloading. ### Expected behavior Each row (corresponding to the reception of a product) and its corresponding header is printed properly, regardless of how many pages constitute the report. ### Unexpected behavior The PDF has more than one page, and on the top of the second page, the product row is overlapped with the header of its corresponding section. ## Origin of the issue It comes from an issue with WKHtmltopdf itself: wkhtmltopdf/wkhtmltopdf#1524 The report uses the "thead" tag for the headers. However, in some cases, when the header is linked to a table dynamically (with for-each, for example), WebKit ignores or breaks the "Thead" behavior. ## Explanation of the fix I override the default behavior of thead, which repeats the header automatically at each new page, with a new style. Now, the "Thead" special behavior is ignored and treated like ordinary lines. The header isn't shown at each new page anymore, avoiding the overlapping of product rows. closes #215398 Signed-off-by: William Henrotin (whe) <[email protected]>
To_reproduce: ============== 1- switch company. 2- update any other company currency that has journal items. 3- company currency changed. Problem: ========= - When switching companies, users could update the other company's currency even when journal items existed for that company. Solution: ========= - Added .sudo() to the account.move.line search to bypass access rights and properly detect existing journal items in that company. opw-4920206 closes #217988 X-original-commit: ee612ac Signed-off-by: Josse Colpaert (jco) <[email protected]> Signed-off-by: Saif Allah Ben Khalil (sben) <[email protected]>
For database with big invoice volume, it is necessary to be able to retrieve documents in smaller batches otherwise crons will timeout due to the 15 minutes limit. Add a retrigger mechanic to the possibly heavy crons. opw-4925532 closes #218383 Signed-off-by: Antoine Dupuis (andu) <[email protected]>
**Current behavior:** When importing a res.country record, if specifying a `name` then the search performed expects it to exactly match a first-letter-only capitalized pattern. **Expected behavior:** Let arbitrary capitalization be used on the input name string. **Steps to reproduce:** 1. Create a sheet to import to `Contacts` (res.partner) * `name`: anything * `country_id`: "ARMENIA" 2. Load the sheet for import -> test -> can't resolve country name **Cause of the issue:** The `res.country` records' names follow a first-letter-capitalized pattern and we do an exact search on the strings. **Fix:** Use `capitalize()` on the input value when we do the search, which will transform the string into precisely the form we want. opw-4780334 closes #216870 Signed-off-by: Chong Wang (cwg) <[email protected]>
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