Monday, January 6, 2025
13 changes · saas-17.2
Miscellaneous changes
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines.  **Expected:** Accountants should be allowed to manage the products database. **Steps to reproduce:** - Activate Invoicing app; - Configure a branch to the company; - Create a user with an accounting `Accountant` role and set the branch company as only entry in Allowed Companies and as Default C
Original PR description
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines. …
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines.  **Expected:** Accountants should be allowed to manage the products database. **Steps to reproduce:** - Activate Invoicing app; - Configure a branch to the company; - Create a user with an accounting `Accountant` role and set the branch company as only entry in Allowed Companies and as Default Company;  - Log in as that new user; - Try create a new product through a Customer Invoice or a Vendor Bill. **Cause:** The `Accountant` role itself has no right on products. **Fix:** Reset a previously removed (february 2023 (saas-16.2) odoo/odoo@512574861691f425ec6a17f20fe4b586bb88a299) access right on `product_template` for group `group_account_manager`.  **Note:** This PR replaces https://github.com/odoo/enterprise/pull/75453 after discussion with reviewer. opw-4293151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190360
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:
Original PR description
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…
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 PR NOTE: this could be merged in an higher version, and we could also just not fix this since as far as I can tell, we only need to support 256x256 and with and without the fix there is just one pixel of difference in this case.  Forward-Port-Of: odoo/odoo#192091
Steps to reproduce: initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report. - Create a new accounting report - Select "Composite Report" - Add the General Ledger as a section - Save -> When navigating to the General Ledger, it no longer has the "unfold all" option selected. Solution provided: If the report is accessible, should not change its fields when being added to a composite rep
Original PR description
Steps to reproduce: initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report. - Create a new accounting report - Select "Composite Report" - Add the General Ledger as a section - Save -> When navigating to the General Ledger, it no longer has the "unfold all" option selected. Solution provided: If the report is accessible, should not change its fields when being added to a composite report. task-4317649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188476
Before this commit, "search more" would not find any matches if searching partners by VAT numbers. After this commit, it becomes possible to search and "load more" partners by VAT number. opw-4379852 Forward-Port-Of: odoo/odoo#190621 Forward-Port-Of: odoo/odoo#189703
Original PR description
Before this commit, "search more" would not find any matches if searching partners by VAT numbers. After this commit, it becomes possible to search and "load more" partners by VAT number. opw-4379852 Forward-Port-Of: odoo/odoo#190621 Forward-Port-Of: odoo/odoo#189703
Currently, a traceback is occurring when the user tries to delete archived product variants. To reproduce this issue: 1) Install sale and enable product variants from configuration 2) Create a product from the variant and archive it 3) Now try to delete the above archived product. Error:- ``` KeyError: 2 ``` When the user archives a product and tries to delete the archived product, we get the `product_ids_by_template_id` as an empty dict. https://github.com/odoo/odoo/blob
Original PR description
Currently, a traceback is occurring when the user tries to delete archived product variants. To reproduce this issue: 1) Install sale and enable product variants from configuration 2) Create a product from the variant and archive it 3) Now try to delete the above archived product. Error:- ``` KeyError: 2 ``` When the user archives a product and tries to delete the archived product, we get the `product_ids_by_template_id` as an empty dict. https://github.com/odoo/odoo/blob/f118a44c5b15163556e3388c5a7daa72119f58f8/addons/product/models/product_product.py#L384-L388 This leads to the above traceback when accessing the product template id from an empty dict from the below line. https://github.com/odoo/odoo/blob/f118a44c5b15163556e3388c5a7daa72119f58f8/addons/product/models/product_product.py#L395 sentry-6173505059 Forward-Port-Of: odoo/odoo#191761
* STEP TO REPRODUCE: install event (only CE code), go to Registration Desk then hit button < to go back -> The system warning there are no gantt view * Solution: using existing action `action_event_view` with `clearBreacrumbs` which will help display the menu correctly 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
Original PR description
* STEP TO REPRODUCE: install event (only CE code), go to Registration Desk then hit button < to go back -> The system warning there are no gantt view * Solution: using existing action `action_event_view` with `clearBreacrumbs` which will help display the menu correctly 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 Forward-Port-Of: odoo/odoo#191295
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 it
Original PR description
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]: https://github.com/odoo/odoo/commit/0de634965a0dec4470b30154f3722a1e83b0e866 task-4428845 opw-4383641 Forward-Port-Of: odoo/odoo#192164 Forward-Port-Of: odoo/odoo#191548
This commit uses the `inset-inline-start` CSS property instead of `left` to account for RTL languages. (No linked task) Forward-Port-Of: odoo/odoo#191342
Original PR description
This commit uses the `inset-inline-start` CSS property instead of `left` to account for RTL languages. (No linked task) Forward-Port-Of: odoo/odoo#191342
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, the leave was not split to take into account the public holiday Solution: ========= - split the leave to take into account the public holiday opw-4353988 --- I co
Original PR description
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, the leave was not split to take into account the public holiday Solution: ========= - split the leave to take into account the public holiday opw-4353988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192376 Forward-Port-Of: odoo/odoo#191552
Steps to reproduce: - Configure a kiosk to have multiple languages - Observe that the language can be changed in the kiosk UI as expected - Install the website module, and configure the website's languages to not include one of the kiosk languages - For example, kiosk has EN and FR, website just has EN - Observe that the language can no longer be changed in the kiosk opw-4403828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-O
Original PR description
Steps to reproduce: - Configure a kiosk to have multiple languages - Observe that the language can be changed in the kiosk UI as expected - Install the website module, and configure the website's languages to not include one of the kiosk languages - For example, kiosk has EN and FR, website just has EN - Observe that the language can no longer be changed in the kiosk opw-4403828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191137
Description of the issue/feature this PR addresses: - A recent change in the contact's list view introduces a small bug, due to which, now a blank column for display name appears. commit ensure correct attribute value for list view. - [commit](https://github.com/odoo/odoo/commit/76aa55dbfcce535d645270448b096ed8cfede104) that introduces issue. Current behavior before PR: - a blank column is visible  that introduces issue. Current behavior before PR: - a blank column is visible  Desired behavior after PR is merged: - `display_name` field is hidden properly.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191887
Refund order in spain require a refund reason. Steps to reproduce: ------------------- * Install l10n_es_pos_tbai module * Open PoS * Make an order and try to refund it > Observation: You get an error message saying that you need to add a refund reason opw-4282586 Forward-Port-Of: odoo/odoo#191205
Original PR description
Refund order in spain require a refund reason. Steps to reproduce: ------------------- * Install l10n_es_pos_tbai module * Open PoS * Make an order and try to refund it > Observation: You get an error message saying that you need to add a refund reason opw-4282586 Forward-Port-Of: odoo/odoo#191205
Changing a product template's image with the `can_image_1024_be_zoomed` field present in the view produces a crash on save. **STEPS TO REPRODUCE** 1. Open a product form view 2. Using studio, add the `can_image_1024_be_zoomed` field 3. Change the image and save The product will be updated, but this error will be thrown: ``` binascii.Error: Incorrect padding ``` **CAUSE** https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/product/models/product_tem
Original PR description
Changing a product template's image with the `can_image_1024_be_zoomed` field present in the view produces a crash on save. **STEPS TO REPRODUCE** 1. Open a product form view 2. Using studio, add the…
Changing a product template's image with the `can_image_1024_be_zoomed` field present in the view produces a crash on save. **STEPS TO REPRODUCE** 1. Open a product form view 2. Using studio, add the `can_image_1024_be_zoomed` field 3. Change the image and save The product will be updated, but this error will be thrown: ``` binascii.Error: Incorrect padding ``` **CAUSE** https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/product/models/product_template.py#L186-L188 In the `RecordSet`'s context, `bin_size=True`, so accessing `image_<size>` returns a size instead of a binary. `_compute_can_image_1024_be_zoomed` calls `tools.is_image_size_above` with this binary size, while the method expects the full base64 encoded image. Ultimately, this causes `base64.b64decode` to crash with the above error. **FIX** Update the `RecordSet`'s context to `bin_size=False`. Accessing `image_<size>` from the `RecordSet` will then return the full binary instead of the size. **NOTES** In versions <17.0, read and write were done in separate network calls causing the recompute to happen during the flush of the write, which doesn't have `bin_size=True` in the context. Because the field is stored, the read will not cause a recompute and thus avoids any error. In >=17.0, because the read occurs before the flush, and the write has invalidated the field, the recompute will occur with the context of the read (`bin_size=True`), causing the issue. opw-4413647 Forward-Port-Of: odoo/odoo#192047