[16.0-irc] Update repo to latest changes from 16.0 #609
Conversation
This file contains 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
We need to check the keys we want to use in `__getitem__` and `__delitem__`. task-4281663
country_id in test closes odoo#187821 Userwarning: unsupported operand type(s) for "==": 'res.country()' == '233' Signed-off-by: William Braeckman (wbr) <[email protected]>
This commit fixes an issue about the dark mode switch overlapping its label. To handle the issue, we just need to apply a width utility class. task-4344243 closes odoo#187688 Signed-off-by: Pierre Paridans (app) <[email protected]>
Commit [1] made sure that when pasting within blockquote and pre the pasted tag are not unwrapped. But the commit did not change the title as well as the describe of the test cases. This commit places the test cases at correct place. [1]: 460d88a closes odoo#187724 Signed-off-by: David Monjoie (dmo) <[email protected]>
Steps to reproduce: Go to the Todo app. Open a task. Write any text. Select the text. Type /command Hit Enter. Before this commit: The command is correctly added, but the issue is that the selected text is also re-added after the command is applied. After this commit: Selected text from before the /command will be removed and commands will still be executed. The process now involves clearing the content first and then launching the command. task-3487792 closes odoo#175808 Signed-off-by: David Monjoie (dmo) <[email protected]>
Before this PR, one-letter domain (like https://x.com) would not be linkified. This PR allows one-letter domain. Task-4344826 closes odoo#187899 Signed-off-by: Matthieu Stockbauer (tsm) <[email protected]>
Issue ===== When a GS1 barcode is scanned, if it starts with a FNC1, it can't be parsed. How to reproduce ================ - In Inventory Settings, select "Default GS1 Nomenclature" as the used nomenclature; - Create a product with a valid EAN13 as barcode (eg. 1234567891231); - Open the Barcode app, then the Inventory Adjustments; - Scan a GS1 barcode for the created product who start with the FNC1 (eg. "\x1D0101234567891231") -> The product's barcode is not decoded. Solution ======== To fix this issue, before to be parsed, the given barcode will be cleaned and if it starts with a FNC1, it will be removed from the string. opw-4118637 closes odoo#187875 Signed-off-by: Arnold Moyaux (arm) <[email protected]>
Since odoo/odoo@4d2aa271 we cannot add any manual field to `res.users`. We are always faced with the error: ``` ... fields used for ordering must be present on the model and stored. ``` ``` >>> u=self.env['ir.model'].search([('model','=','res.users')]) >>> u._check_order() Traceback (most recent call last): File "<input>", line 1, in <module> u._check_order() File "/home/odoo/src/odoo/16.0/odoo/addons/base/models/ir_model.py", line 269, in _check_order raise ValidationError(_("Unable to order by %s: fields used for ordering must be present on the model and stored.", field)) odoo.exceptions.ValidationError: Unable to order by name: fields used for ordering must be present on the model and stored. ``` The reason is that `res.users.name` field is inherited from the parent model `res.partner`. Similarly if we install `base_automation` we cannot add any field to `base.automation` model, because they are ordered by `sequence` coming from its parent model. In this patch we propose to extend the check for field used in `_order` to inherited stored fields. closes odoo#187629 Signed-off-by: Alvaro Fuentes Suarez (afu) <[email protected]>
Before this commit: Some logger.error(...) were ambigious and would just catch the exception to log it's error name without much details. Therefore it was wasting time trying to figure the cause of the error as we lack the traceback details After this commit: Most of them were switch to logger.exception which does add the Exception information to the logging messages automatically. Which include the error message alongside the full traceback. Log messages were also rewrote to be more comprehensive than the: "An error encountered" closes odoo#186162 Signed-off-by: Yaroslav Soroko (yaso) <[email protected]>
This commit fixes the direction of the arrows in the stock rules diagram if the user languange is right-to-left. opw-4302429 closes odoo#187921 Signed-off-by: Arnold Moyaux (arm) <[email protected]>
Currently, customers are unable to invoice orders through a pos session if they use the Bulgarian localization. Steps to reproduce: ------------------- * Install **point_of_sale** and **l10n_bg** * Change the current company to the Bulgarian one * Set up a shop and open it * Make an order, select any customer * Select payment * Select the invoice option * Select payment method and validate > Observation: Traceback appears psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_accountable_required_fields" Why the fix: ------------ The constraints is violated because the value for account_id does not exist. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/point_of_sale/models/pos_payment.py#L115-L117 We observe that `self.company_id.account_default_pos_receivable_account_id.id` is not set. This field belogns to the `account` module but can only be modified if the module `account_accountant` because of the group `group_account_readonly`. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/point_of_sale/views/res_config_settings_views.xml#L163-L167 Other localizations do not have the issue as they set the default account through the data in `account`module. https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/l10n_au/data/account_chart_template_data.xml#L14 https://github.com/odoo/odoo/blob/4601acea15feea4780269b4a333f18435904b684/addons/l10n_au/data/account.account.template.csv#L8 opw-4279804 closes odoo#186551 Signed-off-by: Ruben Gomes (rugo) <[email protected]>
Versions -------- - 16.0+ Steps (16.0+) ------------- 1. Create a no-variant attribute with multiple values; 2. Create a product and assign it those attributes; 3. Add an extra product media from the sales tab; 4. Go to the website and add an extra image through the web editor; 5. Go back and check the extra product media field. The only image displayed is the one you uploaded in step 3. Issue ----- Both images should be shown as this product only has no-variant attributes so they don't create product variants. Cause ----- In Step 4, the uploaded image is saved to the product variant based on the evaluation of the `has_configurable_attributes` field on the product template and the presence of the variant. Solution -------- Check if the attributes are all `no_variant`. In that case, no product variant is created, so the images should be saved on the product template. opw-4174331 closes odoo#187544 Signed-off-by: Valentin Chevalier <[email protected]>
This commit replaced direct use of `NotNullViolation` for psycopg2 2.7, where `psycopg2.errors` does not exist. Now we capture directly `psycopg2.Error` and verify SQLSTATE code (`23502`) for `NOT NULL constraint violations``. closes odoo#187989 Signed-off-by: Rémy Voet (ryv) <[email protected]>
When a SO is partially invoiced, and we change the 'Invoicing Switch Threshold' such that the partial invoices are before the new threshold, the SO will not take invoices into account for computation of amount to invoice / invoiced. Steps to reproduce (needs account_accountant installed): - Create a SO with a line having prod invoiced on delivery and qty 3 - Set delivered quantity to 1 - Click Create Invoice > create the draft invoice, set a date in the past - Set Settings > Accounting > Invoicing Switch Threshold to today - Check Sales Analysis, enable Untaxed Amount Invoiced - Back to the SO, set delivered quantity to 2 - Click Create Invoice > create a new draft invoice - Check Sales Analysis again Issue: Untaxes amount invoiced will be reset to 0, because the system takes into account only the latest invoice, while it should account also for the legacy invoices opw-4295531 closes odoo#187211 Signed-off-by: John Laterre (jol) <[email protected]>
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company Tagline (any value), save, then delete it completely. 5. Go back to Accounting > Invoices and print any invoice. You can notice that the grey line and the text on the top right corner is more down compare to the first printed report. When the Company Tagline `report_header` is cleared, it leaves an extra newline in the report because the HTML editor sets it to `<p><br></p>` instead of `false`. This causes the printed invoice layout to shift. As a solution I added a conditional check in the XML template to only display the `report_header` if it’s not empty (`<p><br></p>`). Alternative solutions considered: 1. Clean the `report_header` field before saving it to the database OR use an on-change function to remove empty values. 2. Implement a custom widget or JS hook for better control. The chosen solution is the simplest, requiring minimal code changes to address the issue effectively. opw-4247281 closes odoo#186023 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Issue: ====== `enter` command doesnt work properly for `pre` element inside list element. Steps to reproduce the issue: ============================= - Add a list - Add a code block with `/code` - Add sone text - Put the cursor at the end of the text - click `enter` - It adds a `br` element and puts the selection at the start. Origin of the issue: ==================== The `oEnter` function of the `pre` element is triggered which adds a `p` element just after the `pre` element inside the same `li` element. Now in sanitiwe we unwrap the p elements inside `li` which leaves us with only a `br` after the `pre`. Since we put the selection at the start of the newly added then removed `p` element, the final selection will not behave correctly. Solution: ========= We single out the case when the parent element of the `pre` is a `li` and treat it as a break inside a `li`. task-4187676 closes odoo#180268 Signed-off-by: David Monjoie (dmo) <[email protected]>
Before this commit, a KeyError would occur if 'entryPointType' was missing in the entryPoints dictionary. opw-4009884 closes odoo#188002 Signed-off-by: Arnaud Joset (arj) <[email protected]>
Issue: When printing the PDF of a Purchase Order, if the company has multiple address, those appear on the same line. Steps to reproduce: - Create a Mexican Company with 2 address lines - Create a Purchase Order - Print the PDF of the Purchase Order Cause: The separator between the 2 address lines in the address format is set as a blank space. Solution: Replace the blank space separator with a new line. closes odoo#186926 Signed-off-by: Claire Bretton (clbr) <[email protected]>
**Current behavior:** With a product that is invoiced based on ordered qty, has avg costing, and real time valuation: it is possible to invoice and received quantity in such an order that, when there is a landed cost associated with an invoice instance of the product, the standard price of the product may be updated with an incorrect value. **Expected behavior:** Product cost follows 'average' selection logically. **Steps to reproduce:** *Enable anglo-saxon accounting* 1. Create a product with: * real time property valuation * average cost method * on ordered quantities control policy 2. Create a purchase order for the product, for 100 000 units of the product at 1.35 each -> confirm the order 3. Create an invoice for 23 000 units, receive 23 000 units and backorder the rest 4. Create a landed cost on the invoice for 23 000 in the company currency units 5. Post the invoice 6. Create a second invoice for 27 000 units and post it 7. Receive 27 000 more units from the receipt 8. See that the product standard price is not the expected value of 1.81 **Cause of the issue:** The landed cost on the invoice is not taken into account. Since the price unit for the moves informing the new price value are obtained with `_get_price_unit()`, we end up only taking into account the sum value of the invoice lines linked to the move. So the landed cost does not get included in the subsequent price unit calculation here: https://github.com/odoo/odoo/blob/22e7bfb591c43e849c554eb4c128279d76ad31f9/addons/stock_account/models/stock_move.py#L328 **Fix:** Extract a method which returns invoice lines to the `_get_price_unit()` method of purchase_stock so that we may return line records that represent landed costs that will otherwise be omitted. opw-4048396 closes odoo#185889 Signed-off-by: William Henrotin (whe) <[email protected]>
When trying to add a DNI number from the user portal, the following error appears: The CUIT number [] does not seem to be valid. Note: the expected format is AR200-5536168-2 or 20055361682 How to reproduce the issue: - Install the Argentinian localization - Create a contact with an email, Identification Number on DNI - Grant them portal access - In users, change the password of the new contact - Log in to the user portal with the new contact credentials - In edit details, enter a DNI number and confirm The solution is a backport of this commit: odoo@caf6bbc#diff-abaa067ec8ef765ce398468a0dd52d47ea3585a90fa61e5276daa1e603b3b232R67 opw-4267173 closes odoo#185948 Signed-off-by: Antoine Dupuis (andu) <[email protected]>
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: ============================= - Create a mass mailing - choose welcome message template - add subject, mailing list and save - Add image using /image and switch directly to another tab like `a/b testing` - Go back to mail body => changes aren't saved. - Same if you replace an existing image with another one Origin of the issue: ==================== - For Newly inserted images we need to refocus in the editor like we did in the old commit. - Now for both of them after the refocus fix we still have an issue because the `saveModifiedImagesPromise` will take so much time so that after it gets resolved the component is already destroyed and we will not save the changes. Solution: ========= We force the commitChanges coming from mass_mailing as urgent so it will save the value before resolving any promise to make sure we don't loose the content. opw-3947516 [commit]: odoo@146b0b9 closes odoo#182615 Signed-off-by: David Monjoie (dmo) <[email protected]>
…oice date Currently, an error occurs when the user attempts to preview an invoice, and invoice date is not available. Step to produce: - Install the 'account' module. - Create a new invoice, add a customer name and invoice line, and add a 'Payment Terms' which have an 'Early Discount' available. - 'Cancel' this invoice. - Click on the 'Preview' button (ensure that the invoice has no date). TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta' An error occurs when the system attempts to calculate the discount days with the invoice date, but the invoice date is not available there. To resolve this issue, we hide the preview button on canceled invoices. Sentry-6006569495 closes odoo#184817 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <[email protected]>
closes odoo#188077 Signed-off-by: Martin Trigaux (mat) <[email protected]>
Setting sudo(False) was no assigning to the proper environment : ValueError: Compute method failed to assign res.partner.bank(8,).display_name Add test (failing in 17.0 enterprise) Courtesy of Dawn Hwang Fixes odoo#187811 opw-4341077 closes odoo#187772 Signed-off-by: Martin Trigaux (mat) <[email protected]>
Since [1], the _is_indexable_url() method was introduced to determine whether a website should be indexed. However, if a domain name contains uppercase letters, the method incorrectly returns a falsy value. This happens because browsers automatically convert URLs to lowercase, causing a mismatch. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with uppercase letters (e.g., http://TEST.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://TEST.localhost:8069/robots.txt and notice that the changes are not reflected. This commit resolves the issue by handling uppercase letters in domain names correctly. [1]: odoo@49c226a opw-4306840 closes odoo#187690 Signed-off-by: Quentin Smetz (qsm) <[email protected]>
…tion Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description column only one translation displays and not both as it should. Cause: The code was changed to only display the current language in this commit (odoo@67b0415) The goal of this commit was to prevent the duplication of the product name because it is already contained in line.name. Solution: The way line.name is computed is by taking the sales description (or purchase one) and concatenating it with the product name. It can also be changed manually in the invoice form view under "label". So to display the product name in both languages and this label without any duplicate this commit adds conditions: - the label is always displayed - the Arabic name is dipslayed if the label does not contains it - the English name is displayed if the label does ont contains it and if it is different from the Arabic one (ie if it is translated) opw-4187577 closes odoo#186449 Signed-off-by: Wala Gauthier (gawa) <[email protected]>
Bank statement lines created from the form view won't have an internal_index value set yet. Running balance computation should set a value also on manually deleted lines from the form view as the balance is a computed non-stored field. TT50906 closes odoo#182497 Signed-off-by: Laurent Smet (las) <[email protected]>
For an expense report paid by an employee, the bank account should be set on the employee form and be used to create the Journal Entry and in Register Payment Wizard. task-4206895 closes odoo#181870 Related: odoo/enterprise#71080 Signed-off-by: Olivier Colson (oco) <[email protected]>
Problem: If the product image size is smaller than `$o-avatar-size` or is an SVG without intrinsic size, it uses the original image size or displays as 0px in the case of SVGs without intrinsic size. The desired behavior is for the image to always display at `$o-avatar-size`. Steps to reproduce: - Add a small or SVG image without intrinsic size to a product. - The image will not display correctly. opw-4119433 closes odoo#187983 Signed-off-by: Adrien Dieudonné (adr) <[email protected]>
Steps to reproduce the issue: - In website, edit mode. - Drag and drop a "Picture" snippet onto the page. - Click the image in the "Picture" snippet. - Delete the image by clicking the "Remove" button in the image options. - Inspect the DOM of the "Picture" snippet. - Bug: The figure element which wrapped the image is still there. After this commit, when an image wrapped by a figure element is removed, the figure is also removed. task-4280164 Part-of: odoo#186278 Signed-off-by: Quentin Smetz (qsm) <[email protected]>
Since [1], when an extra menu is displayed due to the top menu exceeding its maximum width, the active class is no longer applied correctly. This issue was introduced during the conversion from jQuery to vanilla JavaScript. Steps to reproduce: - Enter the Website in edit mode. - Navigate to Site > Menu Editor. - Add several menu items until the menu exceeds its maximum width. - Ensure that one of the items in the extra menu redirects to "Contact Us". - Click on the "Contact Us" menu item. - Open the dropdown menu (via the "+" icon) and observe that the "Contact Us" entry is not highlighted. This commit resolves the problem. [1]: odoo@0de6349 task-4428845 opw-4383641 closes odoo#191548 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Steps to reproduce
==================
- Add a daterange widget to an x2many view (with studio)
- Open the picker
- Click on the next month
=> The picker closes
Cause of the issue
==================
The previous/next handler [0] rerenders the datetime picker.
By the time the list renderer intercepts the click, the ev target is no
longer connected to the DOM. This means that
`.closest(".daterangepicker")` returns nothing.
Solution
========
We can add a property `isFromDateRangePicker` to the event in the
capture phase and check that after the rerender.
---
[0]: https://github.com/odoo/odoo/blob/2a1857db4bee43ff266b4be279791c9b5c957085/addons/web/static/lib/daterangepicker/daterangepicker.js#L1231-L1253
opw-4375790
closes odoo#191914
Signed-off-by: Aaron Bohy (aab) <[email protected]>
Steps to reproduce: - Install hr_timesheet (with demo data) - Navigate to portal > timesheet - Group by project Issue: When only the hr_timesheet module is installed and timesheets are grouped in the portal view, the column alignment is broken due to an incorrect colspan. Cause: When groupby is applied, the colspan is manually set to 4, causing misalignment between the header and row columns. Fix: This commit sets the last column's colspan to 2 when grouping is applied to fix the alignment issue. task-4294780 closes odoo#186532 Signed-off-by: Xavier Bol (xbo) <[email protected]>
…e wizard Steps to reproduce: 1. Log in with a non-admin users 2. Open any Partner from 3. Click on Actions > Privacy Lookup Bug: ``` You are not allowed to access 'Privacy Lookup Wizard' (privacy.lookup.wizard) records. This operation is allowed for the following groups: - Administration/Settings Contact your administrator to request access if necessary. ``` Expected behavior: The error message is correct. This feature should only be available to Administrator users. Therefore, the action should be hidden accordingly. closes odoo#150748 Signed-off-by: Yannick Tivisse (yti) <[email protected]>
And compress the arabic language closes odoo#192210 Signed-off-by: Martin Trigaux (mat) <[email protected]>
This reverts commit ff37026 After which customer credit notes share the sequence with supplier credit notes. Steps to reproduce: - Open Vendor Bills journal and enable 'Use Documents?' - Create a Bill with document type '(46) Factura de Compra Electrónica' - Create the credit note - In the Wizard: select 'Full Refund', Document Type 61, Confirm - Document name will be 'N/C 000001' - Now create an invoice with document type '(33) Factura Electrónica' - Add a credit note for the invoice Issue: Credit note name will be 'N/C 000002' but sequences should be unique for move type opw-4268371 closes odoo#192285 Signed-off-by: Josse Colpaert (jco) <[email protected]>
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center Issue: Reportlab QrCodeWidget has a fixed size to 32mm (with mm that is 72(ppi) / 25.4(1mm to inch) so ~2.83 pixels) and to get the widget to the full size, a zoom is applied on the Drawing content (so on the QrCodeWidget). Here are the zoom that are applied for several Drawing size: - for 100 pixels: 100 / (32 * mm) => 1.012… - for 256 pixels: 256 / (32 * mm) => 2.822… - for 400 pixels: 400 / (32 * mm) => 4.409… But in the code, the zoom is just hardcoded to mm (~2.83) which corresponds to a barcode size of mm * 32 * mm => 257.127 pixels which is kind of good enough for 256 pixels, but wrong for most other size. In base code we only use 256 x 256 pixels so this is not much of an issue unless someone want to use it for something else. Fix: With this commit, we apply the Drawing zoom (on which we have the QrCodeWidget) to the ch_cross image. Note: Without the fix, the added test only fail on the third assertion for each loop iteration, the farer we are from 257x257 pixels the bigger the error is, for example for 256x256: Result: (38.45140, 38.45140, 52.25725984251969, 52.25725984251969) Expected: (38.28288, 38.28288, 52.02823111111111, 52.02823111111111) opw-4307177 closes odoo#192091 Signed-off-by: Antoine Dupuis (andu) <[email protected]>
**Problem**: When selecting all content (`Ctrl+A`) in an empty editable area, the selection includes only a `<br>` element. This causes issues when interacting with non-selectable content inside the selection, leading to unexpected behavior. **Solution**: If the selection contains only on `br` element, reset the selection on click to avoid inconsistent states. **Steps to Reproduce**: 1. Open the editor. 2. Press `Ctrl+A` to select all. 3. Click anywhere within the editable area to hide the toolbar. 4. Observe that the toolbar remains visible, and the selection state does not update. opw-4438513 closes odoo#192084 Signed-off-by: David Monjoie (dmo) <[email protected]>
…y public holiday to reproduce: ============= - create a leave for an employee of 3 days - create a public holiday that happens to be in the middle of the employee leave - check work entries for the employee on that period -> only work entries of the public holiday are created Problem: ======== - when the public holiday was created we reevalute the leaves that can be affected by the public holiday, so they are set to `state='draft'` which will unlink resource leaves records that are linked to them, but these resource leaves are not recreated at the end of the process Solution: ========= when we unlink the resource leaves we should check if the leave is not fully covered by the public holiday and recreate the resource leave if it was previously validated opw-4353988 closes odoo#191552 Signed-off-by: Yannick Tivisse (yti) <[email protected]>
- add check on `employee_id` to the contract domain to exclude templates from the contract count on the stat buttons as it gives misleading info about the real contracts count closes odoo#192145 Task: 4402795 Signed-off-by: Yannick Tivisse (yti) <[email protected]>
If you create a pricelist rule with a discount that has a valid date range, that discount is only applied if the SO was created in that range. Even if it is confirmed within the valid date range. Fix: For website_sale orders we consider the date to be the current time when computing the price. opw-4375643 closes odoo#192361 Signed-off-by: Victor Feyens (vfe) <[email protected]>
In 862ede4 the added test depended on being in year 2024, so it failed in eg. 2025. With this change we don't harcode the invoice name in assert data. runbot-error-111390 opw-4050777 closes odoo#192192 Signed-off-by: Xavier Dollé (xdo) <[email protected]>
Steps to reproduce:
- Render the Contact qweb widget with fields ["phone", "website"]
```py
Contact = self.env["ir.qweb.field.contact"]
partner = self.env["res.partner"].create(
{
"name": "Test Partner",
"phone": "1234567890",
"website": "https://www.example.com",
}
)
result = Contact.value_to_html(partner, {"fields": ["phone", "website"]})
```
Result:
- The website is not shown
This is a regression introduced in 9e53aea, in combination with some buggy
behavior in the qweb compilation.
Somehow the `t-elif` condition is applying on the next element instead on itself,
hiding the website element. I did not investigate further to find the root
cause, though.
Switching to a `t-if` condition works around the issue.
closes odoo#191201
Signed-off-by: Rémy Voet (ryv) <[email protected]>
closes odoo#191453 Signed-off-by: Julien Castiaux (juc) <[email protected]>
Steps to reproduce: 1. Create two companies: Company A and Company B 2. Create a service product 3. Configure the product to be purchased on Company A and not on Company B 4. Create a sales order on Company B, while logged in Company A 5. Confirm the order Expected result: The service PO is created on Company B, even though it was configured not to. closes odoo#177659 Signed-off-by: Tiffany Chang (tic) <[email protected]>
Issue: In Czech Republic, the rate of the 15% tax has changed to 12%. The new rate has already been handled in l10n_cz, but the OSS mapping still uses the old rate. opw-4310264 closes odoo#192458 Signed-off-by: Habib Ayob (ayh) <[email protected]>
When exporting a SA E-invoice file, the system needs to collect invoice line without downpayment lines. However, when collecting tax values, because of an error correction mechanism, the tax amount will still include the amount of the downpayment tax line Steps to reproduce (with SA localization installed and SA company): - Create a SO of 1000$ with 15% tax - Make a downpayment of 100$ with 15% tax and confirm - Make the final invoice with downpayment deducted - Confirm and send e-invoice for validation Issue: The invoice is validated, but a warning is logged ``` Invoice was Accepted by ZATCA (with Warnings) The invoice was accepted by ZATCA, but returned warnings. Please, check the response below: BR-CO-17: VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals. BR-S-09: The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is Standard rated shall equal the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119). ``` As the warning states the is an issue with the tax computation. When collecting amounts from the final invoice, we should filter out downpayment amounts, but due to the error correction mechanism introduced to account for manual modification of the journal items, the filter is ignored, so we will have the filtered base amount (1000) and the unfiltered tax amount (135 instead of 150) A possible solution is to avoid the error correction when we know we need to filter invoice lines opw-4380798 closes odoo#191867 Signed-off-by: Josse Colpaert (jco) <[email protected]>
Steps to reproduce: - Install l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice with "Simplified Invoice Partner (ES)" as customer - Confirm the invoice - Process the invoice with "TicketBAI (ES)" service Issue: The generated XML has 2 regime keys (02 and 52) for <ClaveRegimenIvaOpTrascendencia> that are not compatible with each other. From the documentation, regime key "52" (for simplified invoices) can only be associated with regime key "51", which is not supported for the moment. Solution: If the "Simplified Invoice Partner" is used, only the regime key "52" is used. opw-4332052 opw-4355424 closes odoo#192448 Signed-off-by: Ricardo Gomes Rodrigues (rigr) <[email protected]>
Before this commit, when a user without access to certain orders attempted to load paid orders, the process would fail and result in an error. This was particularly problematic if a POS order was linked to a sale order that the user did not have permission to access, causing the entire loading process to halt. This commit addresses the issue by filtering out paid orders that the user cannot access. opw-4108044 closes odoo#177592 Signed-off-by: Adrien Guilliams (adgu) <[email protected]>
It is necessary to check that the cursor used to create the instance of the environment is an instance of `BaseCursor` directly at the start of the method (in order to be sure to check it before its first use). Task-4268673
Debugging outgoing emails is tedious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were. In this work we also log the (redacted) To header. We decided to redact the header out of excessive caution regarding the GDPR. The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different email addresses appart (for debugging). Redaction so it hard to find the original email address back (for privacy). It must also be simple. We conducted several experiments using a dataset of 600ish email address (95% of which have a local part that is at least 6 characters long) to determine a nice function. The final function keep the first character for shorter inputs (length of local part < 6) and the first plus two lasts chars for longer inputs (>=6). Using that function we achieve a 99% disambiguation of emails in the dataset (with or without redacting the domain) while retaining minimal info (3 chars at most). Redacting the domain isn't that useful as most addresses use gmail, hotmail, outlook, yahoo. Task-4361561 closes odoo#188697 Signed-off-by: Julien Castiaux (juc) <[email protected]>
**Current behavior:** Having a product which with the purchase control policy of "ordered quantities" and avg costing, if you create a vendor bill for a receipt prior to actually validating it and apply a discount on the bill line then validate the receipt, the valuation fails to reflect the discount. **Expected behavior:** The valuation layer generated by the reception should take into account this discount for the unit_price/price_unit of the layer. **Steps to reproduce:** 1. Create a product with average costing and control policy based on ordered quantities (purchase tab in product form) 2. Create a purchase order for the product at a price unit of 10 -> confirm 3. Create the bill, add a 10% discount, post the bill 4. Validate the receiption -> Valuation -> see that the product is valued at 10 instead of the expected 9 **Cause of the issue:** When the discount is applied in this manner, it is currently not captured in the product's `standard_cost` which is the value which is what will calculate the valuation unit price. **Fix:** In this situation, recalculate the price unit of the invoice line using the subtotal and qty information on the invoice line. opw-4183595 closes odoo#190530 Signed-off-by: William Henrotin (whe) <[email protected]>
Those constraints are blocking the flow for no good reason as we - don't find them in the official documentation - they don't really make sense in the context of a credit note Therefore we decide to remove them for credit notes. They don't seem to be required for the facturx validity. task-4454115 closes odoo#192495 Signed-off-by: Laurent Smet (las) <[email protected]>
Steps to reproduce
==================
- Install industry_fsm,web_studio
- Go to Field Service
- Switch to the calendar view
- Open studio
- Unset the color
=> fields[fieldMapping.color] is undefined
Cause of the issue
==================
We have a field that has the color attribute with a value of color.
```xml
<field name="worksheet_template_id" attrs="{'invisible': [('worksheet_template_id', '=', False)]}" filters="1" color="color"/>
```
`shouldFetchColor` checks if the filter color is the same one as the
calendar record color.
Solution
========
Since it's possible to have a color filter without a record color, we
should fetch the filter colors in that case.
opw-4443497
closes odoo#192334
Related: odoo/enterprise#76454
Signed-off-by: Michaël Mattiello (mcm) <[email protected]>
* = stock * PROPBLEM: when viewing purchase or vendor dashboard (under logistic section) , viewing the scoreboard for purchased or order it calculate all record from purchase.report but when clicking on it, redirect to view of 'purchase order' only which is wrong compare to the number display on the scoreboard * SOLUTION: This commit fix by edit the domain of related pivot which the scoreboard use to display data to the domain having state in either Purchase or Done closes odoo#191985 Signed-off-by: William Henrotin (whe) <[email protected]>
Steps to Reproduce: - Install data_recycle module. - Navigate to Configuration → Rules and create any rule for the data_recycle. Issue: - The selected option for the notify_frequency_period field is not displayed correctly due to a fixed width class (w-25) assigned to its parent <div> element. Solution: - Updated the width class from w-25 to w-50 to ensure proper display of the selected option. opw-4414071 closes odoo#191639 Related: odoo/enterprise#76122 Signed-off-by: Yannick Tivisse (yti) <[email protected]>
This commit removes the existing currency rate before creating the new ones as there is a unicity constrains on the currency rate date. closes odoo#192831 Runbot-error: 111437 Signed-off-by: Arnold Moyaux (arm) <[email protected]>
Two lines that were missing from the "REAGYP - Agricultura" Fiscal Position Tax Mapping have been added. task-4342206 closes odoo#192359 Signed-off-by: Josse Colpaert (jco) <[email protected]>
Steps to reproduce ================== - Open any project - Create many project stages (80+) - Switch to the list view - Group by stage - Switch to to next page => The pager keeps increasing Cause of the issue ================== `stage_id` has a group_expand: `_read_group_stage_ids` This method is used to include empty stages in the result for the kanban view, so that we can drag tasks to an empty stage. Solution ======== Add a context key `project_kanban` and only add empty stages in that case. opw-4408061 closes odoo#192492 Signed-off-by: Xavier Bol (xbo) <[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.
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