Monday, October 21, 2024
38 changes · saas-17.4
Resolved issues and error corrections
The chat interface’s “+X” counter now appears in regular text instead of italics. This small visual fix improves consistency and readability in the ChatHub area.
Original PR description
See the +7 that was italics before Before / After <img width="73" alt="Screenshot 2024-10-21 at 20 55 17" src="https://github.com/user-attachments/assets/3754e36b-5ade-4c28-991c-f3f73cc74d2c"> <img width="61" alt="Screenshot 2024-10-21 at 20 52 36" src="https://github.com/user-attachments/assets/3933af74-8e51-4c0e-8309-2ebbca303bda">
Users editing a message can now save or cancel their changes with a single click. This removes a small but frustrating interaction issue in the mail composer, making message editing feel more reliable.
Original PR description
Before this commit, when editing a message, we had to click twice on "Cancel" or "Save" to register the edit message action. This happens because while clicking on these action for the 1st time, composer intercepts a "focusout" event, which re-renders the template and thus the "Cancel" & "Save" buttons too, thus cancelling their action. The 2nd click doesn't trigger this focusout thus it works. This commit fixes the issue by moving code that generates the "Cancel or Save" text in a sub-component. Doing so ensures that the component is only rendered when needed, in this case when Composer.mode or ui.isSmall change. opw-4119283 Before  After 
The website product configuration dialog title now appears in the shopper's selected language. This fixes a missing translation caused by the title coming from a module whose translations were not loaded on website pages, improving localization consistency for online customers.
Original PR description
On the website, the title of the ProductConfigatorDialog is not translated into any language. This is because only "frontend modules" translations are fetched in the context of the website. The title of the dialog is defined in the "sale" module, which is not a frontend module, so the translation is missing. This commit solves the problem by redefining the string to translate in the website_sale module. Task-4182798
Product and combo configurator labels now use the correct translations on the website. This helps customers see consistent language when choosing product options online, reducing confusion during the buying process.
Original PR description
Backend translations are not loaded in the frontend, and since the product/combo configurators are defined in the backend and overridden in the frontend, any translations used both in the backend and the frontend need to be defined in both. opw-4182798
This fixes an intermittent failure affecting batch payment validation by removing a redundant early check that could run at the wrong time. The same business rule is still enforced when validating the batch, so users keep the intended protection while nightly builds become more reliable.
Original PR description
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly…
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly runbot builds (but weirdly not on regular builds, probably due to the timing of stored fields recomputation and constraint validation). Essentially, the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L170 broke. This happened because, when resetting the payment to draft in the test, we triggered this compute function on the account.payment https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_payment.py#L18. This compute function did not reassign the batch_payment_id field, but the ORM still considered it modified, and hence recomputed the payment method of the batch via this compute function https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L69 . Then, this field triggered the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L149. The test raised then just when initializing the assertRaises, when the stored payment_method_id field of the batch got recomputed. It is possible to force it by flushing at that point, otherwise, it's not exactly deterministic. The part of the constraint ensuring a draft payment cannot be added to a batch is the problem. The test tries to set one of the payments in the batch back to draft, and if this happens, the batch will end up in a state that is inconsistent with its own constraint. We fix the issue by simply removing it. This check is done again anyway when validating the batch payment. Doing things this way, we ensure the scenario of the test works in every case, whatever crazy recomputations happen in the ORM.
Restaurant floor table setup now keeps the appointment resource information available when editing tables directly in the list. This prevents booking-related table settings from being lost or inaccessible after the interface change in version 17.4.
Original PR description
Steps to reproduce: - Install Restaurant and Appointments - in PoS's Settings, enable booking - go to PoS -> Configurations -> Floor plans - Select a floor - There is no "Appointment resource" field in the tree view Initially in 17.2, the tree items in the floor page (the tables) were not editable in place, so clicking on a table opened the form view where we could change the "Appointment resource". However, in 17.4, the tree was made editable in place, but we've missed adding the "Appointment resource" field. This PR adds back the field "Appointment resource" (as hidden field) to the floor tables tree view. The changes in this PR were copied from version 18.0, where this bug was already fixed by [this commit](https://github.com/odoo/enterprise/commit/f240b921dd3548b5f91d947354abc85f947f486b#diff-119979c4226bdf057abdfa1b8bb4572112e12e325e3e3461d0a6f258b792e979R19). opw-4237285
This update adjusts an internal performance test limit for subscriptions after a recent change added one database query when all modules are installed. It helps keep automated checks aligned with the current system behavior without changing customer-facing functionality.
Original PR description
File "/data/build/enterprise/sale_subscription/tests/test_performance.py", line 21, in test_recurring_order_creation_perf
with self.assertQueryCount(__system__=2309):
File "/usr/lib/python3.12/contextlib.py", line 144, in __exit__
next(self.gen)
File "/data/build/odoo/odoo/tests/common.py", line 549, in assertQueryCount
self.fail(msg % (login, count, expected, funcname, filename, linenum))
AssertionError: Query count more than expected for user __system__: 2310 > 2309 in test_recurring_order_creation_perf at /data/build/enterprise/sale_subscription/tests/test_performance.py:21
One more query has been added recently when all modules are installed.
runbot error: https://runbot.odoo.com/web#id=102953&view_type=form&model=runbot.build.error&menu_id=405&cids=1Miscellaneous changes
## Description Following cef5ae8a80988c4e0529c1770b1c1e573490f6e7, the default `batch_size` for generating the mails was changed from `500`->`50`. But one instance seems to have been missed, during the generation of mails in the wizard, which is used by the mass-mailing cron. To address this, we are just changing `self.batch_size` in the wizard from `500`->`50` (the variable may have been overridden in custom code, so we keep the static variable) Backport of ac51f29f91e34cf4794164658a8c27d8
Original PR description
## Description Following cef5ae8a80988c4e0529c1770b1c1e573490f6e7, the default `batch_size` for generating the mails was changed from `500`->`50`. But one instance seems to have been missed, during the generation of mails in the wizard, which is used by the mass-mailing cron. To address this, we are just changing `self.batch_size` in the wizard from `500`->`50` (the variable may have been overridden in custom code, so we keep the static variable) Backport of ac51f29f91e34cf4794164658a8c27d8b7759230 ## Reference opw-4142511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180830
Versions -------- - 16.0+ Steps ----- 1. Create a zero-priced product template; 2. add some attribute values; 3. configure price extras for the attributes; 4. configure eCommerce to prevent sale of zero-priced products; 5. go to eCommerce products page. Issue ----- Product is displayed as "Not Available For Sale," even though you can click on it, select a price-extra attribute, add it to cart, and purchase it. Cause ----- The template doesn't consider potential `price_extra`
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Create a zero-priced product template; 2. add some attribute values; 3. configure price extras for the attributes; 4. configure eCommerce to prevent sale of zero-priced products; 5. go to eCommerce products page. Issue ----- Product is displayed as "Not Available For Sale," even though you can click on it, select a price-extra attribute, add it to cart, and purchase it. Cause ----- The template doesn't consider potential `price_extra` attributes when displaying the not available message. Solution -------- Add a `t-elif` element to the template, checking if the product has any non-zero price-extra attribute values, if so, don't display the not available message, but also don't display the zero price. opw-4225183 Forward-Port-Of: odoo/odoo#184052
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event Sales module, where the wrong price was shown on the product page. For Odoo 17.4+, this issue displayed as a strikethrough on the correct price next to a mistakenly discounted price. For versions prior to 17.4, only the incorrect discounted price was displayed without a strikethrough. This bug onl
Original PR description
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event…
When purchasing event tickets in foreign currencies such as JPY or CAD, Odoo was incorrectly applying small discounts to products even when no discount was intended. This behavior affected the Event Sales module, where the wrong price was shown on the product page. For Odoo 17.4+, this issue displayed as a strikethrough on the correct price next to a mistakenly discounted price. For versions prior to 17.4, only the incorrect discounted price was displayed without a strikethrough. This bug only occurred when the Event Registration product price was set to a value different from the price defined in the Event record. While this bug is present in 16.0 onwards, the logic causing the issue has been refactored and will require a separate fix. Steps to reproduce the issue: 1. Create Pricelists for additional currencies (CAD, JPY) with empty rules and enable the “Selectable” checkbox for Ecommerce. 2. Set currency rates to 133.6200 for JPY and 1.338800 for CAD to replicate the conditions when the bug was found. 3. Create an Event. 4. Create an Event Registration Ticket, ensuring the linked Event Registration product price is $1.00 and the price in the event view is set to $30.00. 5. Visit the Event page on the website and attempt to purchase a ticket. Switch between currencies (JPY, CAD) to observe the issue. 6. Using JPY at the conversion rate of 133.6200, the expected converted price for a $30.00 ticket should be ¥4009, but Odoo calculates the price as discounted to ¥3997. 7. With CAD at 1.338800, the correct converted price should be $40.16 CAD, but the price is instead calculated as $40.12 CAD. 8. On 17.4+, the original and correct prices will display as a strikethrough discount. Cause of the issue: The method _get_contextual_discount in product_product.py was comparing a rounded lst_price to an unrounded contextual price, leading to a tiny discrepancy being mistaken as a discount. The bug occurred because the rounding of the lst_price did not match the rounding of the contextual price. While this method is defined in the product module, it only is used by the event_booth and event_booth_sale modules. Solution: The fix ensures that both operands are not rounded before comparison. Now, the _get_contextual_discount method does not round both the lst_price and the contextual price, preventing the calculation of an erroneous discount. opw-4213704 Forward-Port-Of: odoo/odoo#182695
The code comment says non-internal users should not have access to has_group if it's not for themselves. But the code checked the group of the targetted user, not the current user. Added test failed without fix failed because an AssertError was not raised, and an AssertError was raised when it should not have. note: found when reviewing 18.0 forward-port of d0828eecf60f7c8622d6875b opw-4096073 Forward-Port-Of: odoo/odoo#184207
Original PR description
The code comment says non-internal users should not have access to has_group if it's not for themselves. But the code checked the group of the targetted user, not the current user. Added test failed without fix failed because an AssertError was not raised, and an AssertError was raised when it should not have. note: found when reviewing 18.0 forward-port of d0828eecf60f7c8622d6875b opw-4096073 Forward-Port-Of: odoo/odoo#184207
Steps to reproduce: - install project app - create project without any task - change the language Issue: The helper string is not being translated. Reason: This issue occurs because the existing context is lost, particularly the `lang` variable, which impacts the translation functionality. Solution: In this commit, we have updated the method from with_context({'active_id': self.id}) to with_context(active_id=self.id). This fix ensures that the previous context is ret
Original PR description
Steps to reproduce:
- install project app
- create project without any task
- change the language
Issue: The helper string is not being translated.
Reason:
This issue occurs because the existing context is lost, particularly
the `lang` variable, which impacts the translation functionality.
Solution:
In this commit, we have updated the method from
with_context({'active_id': self.id}) to with_context(active_id=self.id).
This fix ensures that the previous context is retained.
task-3940540
Forward-Port-Of: odoo/odoo#184255
Forward-Port-Of: odoo/odoo#170720This commit fixes an issue with the display of list monetary aggregates where the error message saying that different currencies cannot be aggregated would show even when no aggregate method is set. Steps to reproduce: - Create a list view with monetary field and different currencies - Don't set an aggregation method - An aggregation row is wrongly added and contains the error message Original PR: https://github.com/odoo/odoo/pull/132272 Forward-Port-Of: odoo/odoo#183982 Forward-Port-O
Original PR description
This commit fixes an issue with the display of list monetary aggregates where the error message saying that different currencies cannot be aggregated would show even when no aggregate method is set. Steps to reproduce: - Create a list view with monetary field and different currencies - Don't set an aggregation method - An aggregation row is wrongly added and contains the error message Original PR: https://github.com/odoo/odoo/pull/132272 Forward-Port-Of: odoo/odoo#183982 Forward-Port-Of: odoo/odoo#183730
**Steps to reproduce:** - Install Accounting and l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice: * Customer: [an Italian customer] * Product: [any] * Taxes: [a split payment tax] (e.g. 22% SP) - Confirm the invoice - Process to E-invoicing service - Check the XML of the electronic invoice => <ImportoTotaleDocumento> node is including the tax amount - Create a credit note (Full refund) - Confirm the credit note - Process to E-invoicing service
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice: * Customer: [an Italian customer] * Product: [any] * Taxes: [a split payment tax] (e.g. 22% SP) - Confirm the invoice - Process to E-invoicing service - Check the XML of the electronic invoice => <ImportoTotaleDocumento> node is including the tax amount - Create a credit note (Full refund) - Confirm the credit note - Process to E-invoicing service - Check the XML of the credit note **Issue:** <ImportoTotaleDocumento> node is not including the tax amount. Task [link](https://www.odoo.com/odoo/project/967/tasks/4161435) opw-4161435 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184334 Forward-Port-Of: odoo/odoo#183774
Issue: ====== Extra button in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing - Start from scratch - Drop cover template - Add a link inside it - Test send the email - There is an extra link in the sent email. Origin of the issue: ==================== In the case when the button is inside the cover template we end up with something like this `<!--mso condition ab <!-- another condition cd endif--> ef endif-->` but in reality c
Original PR description
Issue: ====== Extra button in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing - Start from scratch - Drop cover template - Add a link inside it - Test send the email - There is an extra link in the sent email. Origin of the issue: ==================== In the case when the button is inside the cover template we end up with something like this `<!--mso condition ab <!-- another condition cd endif--> ef endif-->` but in reality comments can't be nested so the first comment will close at the ending of the second comment so we will end up with the content `ef` being displayed. Solution: ========= Since the two conditions are opposites, we remove completely the content of the nested comment if it has oppisite condition otherwise we just remove the comment tags since they will be replaced with the upper comment opw-4149948 Forward-Port-Of: odoo/odoo#181504
Just add a missing space in the French translation. Forward-Port-Of: odoo/odoo#184041
Original PR description
Just add a missing space in the French translation. Forward-Port-Of: odoo/odoo#184041
Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1
Original PR description
Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183813 Forward-Port-Of: odoo/odoo#183566
Versions -------- - 17.0+ Steps ----- 1. Enter debug mode; 2. create an Automation Rule; 3. select Task as model; 4. set trigger to Stage is set to New; 5. set domain to a specific customer; 6. add send email as action; 7. create a task. Issue ----- Email is sent after task creation, regardless of the customer. Cause ----- The triggers added to 0a744accc2aa automatically compute the `filter_domain` value, and hide the field in view. With debug mode enabled, the `filter_pre
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enter debug mode; 2. create an Automation Rule; 3. select Task as model; 4. set trigger to Stage is set to New; 5. set domain to a specific customer; 6. add…
Versions -------- - 17.0+ Steps ----- 1. Enter debug mode; 2. create an Automation Rule; 3. select Task as model; 4. set trigger to Stage is set to New; 5. set domain to a specific customer; 6. add send email as action; 7. create a task. Issue ----- Email is sent after task creation, regardless of the customer. Cause ----- The triggers added to 0a744accc2aa automatically compute the `filter_domain` value, and hide the field in view. With debug mode enabled, the `filter_pre_domain` field is still visible & editable. The newly added triggers are applied on both create & update, while `filter_pre_domain` is only applied on update. This leads to confusion when clients add a domain which appears to be ignored, as the selected trigger is immediately hit on creation. Solution -------- 1. Specify in the help string that `filter_pre_domain` is ignored on creation. 2. When entering debug mode, also show the `filter_domain` field, allowing users to further modify the domain computed by the selected trigger, and helping to distinguish itself from `filter_pre_domain`. opw-3928082 Forward-Port-Of: odoo/odoo#180209
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183147 Forward-Port-Of: odoo/odoo#179344
Original PR description
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183147 Forward-Port-Of: odoo/odoo#179344
Issue: ====== clipboard data has ufeff characters in it. Steps to reproduce the issue: ============================= - Create a new note/todo - Add a link - Copy it - Visualise the data copied - It contains ufeff characters of the link Solution: ========= We remove the characters fron the text and html we put in the clipboard data. opw-4029722 Forward-Port-Of: odoo/odoo#182596
Original PR description
Issue: ====== clipboard data has ufeff characters in it. Steps to reproduce the issue: ============================= - Create a new note/todo - Add a link - Copy it - Visualise the data copied - It contains ufeff characters of the link Solution: ========= We remove the characters fron the text and html we put in the clipboard data. opw-4029722 Forward-Port-Of: odoo/odoo#182596
- Create a Sales Order, add a product and confirm - Open POS session - Click Quotations/Order button - Select the created SO - Apply a downpayment - Validate the downpayment order - Go back to the Sales Order - Deliver the product if necessary - Click 'Create Invoice' Issue: The downpayment amount paid via POS is not taken into account in computation of 'Already invoiced' and 'Amount to invoice' A solution is to add a component to keep track of the downpayments made via POS op
Original PR description
- Create a Sales Order, add a product and confirm - Open POS session - Click Quotations/Order button - Select the created SO - Apply a downpayment - Validate the downpayment order - Go back to the Sales Order - Deliver the product if necessary - Click 'Create Invoice' Issue: The downpayment amount paid via POS is not taken into account in computation of 'Already invoiced' and 'Amount to invoice' A solution is to add a component to keep track of the downpayments made via POS opw-4131695 Forward-Port-Of: odoo/odoo#184177 Forward-Port-Of: odoo/odoo#178844
**Current behavior before PR:** When link-preview is done on public channel invitation links it posts a guest joined the channel message in the public channel. **Desired behavior after PR is merged:** now we are ignoring public channel invitations links for link-preview, so it does not post guest joined the channel backported PR: https://github.com/odoo/odoo/pull/178932 which handle's ignore link-preview. task-4083161 --- I confirm I have signed the CLA and read the PR guid
Original PR description
**Current behavior before PR:** When link-preview is done on public channel invitation links it posts a guest joined the channel message in the public channel. **Desired behavior after PR is merged:** now we are ignoring public channel invitations links for link-preview, so it does not post guest joined the channel backported PR: https://github.com/odoo/odoo/pull/178932 which handle's ignore link-preview. task-4083161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183817 Forward-Port-Of: odoo/odoo#180187
Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 Forward-Port-Of: odoo/odoo#182414 Forward-Port-
Original PR description
Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 Forward-Port-Of: odoo/odoo#182414 Forward-Port-Of: odoo/odoo#178829
Steps to reproduce : ------------------------- - Install the pos_restaurant module. - Create a restaurant with no floors. - Open Restaurant and click on edit plan button. - Try to do anything from editing options. Issue : -------- As there are no floor exists neither of the options works and some will give tracebacks. Cause : --------- Without any floor we were trying to change properties of the floor. Fix : ---- We will check if any floor exists for that config then only the
Original PR description
Steps to reproduce : ------------------------- - Install the pos_restaurant module. - Create a restaurant with no floors. - Open Restaurant and click on edit plan button. - Try to do anything from editing options. Issue : -------- As there are no floor exists neither of the options works and some will give tracebacks. Cause : --------- Without any floor we were trying to change properties of the floor. Fix : ---- We will check if any floor exists for that config then only the edit plan button will be visible. Forward-Port-Of: odoo/odoo#184079 Forward-Port-Of: odoo/odoo#182702
Versions -------- - 17.0+ >[!Note] > For 17.4+, I had to add a value provided by the delivery controller in order to fix this bug, as well as fix a regression caused by its removal in https://github.com/odoo/odoo/pull/153063 > More details in this comment below: https://github.com/odoo/odoo/pull/181325#issuecomment-2383041670 Steps ----- 1. Create a coupon with free shipping reward; 2. create an eWallet with enough points for a free purchase; 3. create at least 2 shipping methods
Original PR description
Versions -------- - 17.0+ >[!Note] > For 17.4+, I had to add a value provided by the delivery controller in order to fix this bug, as well as fix a regression caused by its removal in…
Versions -------- - 17.0+ >[!Note] > For 17.4+, I had to add a value provided by the delivery controller in order to fix this bug, as well as fix a regression caused by its removal in https://github.com/odoo/odoo/pull/153063 > More details in this comment below: https://github.com/odoo/odoo/pull/181325#issuecomment-2383041670 Steps ----- 1. Create a coupon with free shipping reward; 2. create an eWallet with enough points for a free purchase; 3. create at least 2 shipping methods with different prices; 4. in eCommerce, add a product to cart, and go to checkout; 5. apply coupon; 6. go to payment & apply eWallet; 7. switch between shipping methods. Issue ----- The eWallet amount on the right doesn't get updated after changing shipping costs. Cause ----- Commit e08449e42a01 allowed for eWallet to update after changes, using a `_handleCarrierUpdateResultBadge` override. Commit 453c6169e080 merged the `_handleCarrierUpdateResult` & `_handleCarrierUpdateResultBadge` methods. Because of an `else` that was left in by accident, it either displays a shipping discount *or* it updates the eWallet. Solution -------- Remove the stray `else` so that the conditional branches are no longer mutually exclusive. opw-4150258 Forward-Port-Of: odoo/odoo#181262 Forward-Port-Of: odoo/odoo#180347
Issue: ====== Empty inline code block isn't working as expected and produces issues in the following flows: First Flow: - Create a note - Add ` 2 times - Delete forward 2 times - The button send message is modified!! Second Flow: - Log a note in the chatter of the note - Open composer - Add ` 2 times - Delete forwart 2 times - Traceback Origin of the issue: ===================== After adding the {backtick} 2 times, it will have the following html `<p>{backtick}[]<code cla
Original PR description
Issue: ====== Empty inline code block isn't working as expected and produces issues in the following flows: First Flow: - Create a note - Add ` 2 times - Delete forward 2 times - The button send…
Issue:
======
Empty inline code block isn't working as expected and produces issues in
the following flows:
First Flow:
- Create a note
- Add ` 2 times
- Delete forward 2 times
- The button send message is modified!!
Second Flow:
- Log a note in the chatter of the note
- Open composer
- Add ` 2 times
- Delete forwart 2 times
- Traceback
Origin of the issue:
=====================
After adding the {backtick} 2 times, it will have the following html
`<p>{backtick}[]<code class="o_inline_code">{backtick}</code></p>` which
is not the expected behavior. now after delete forward we will have the
following html
`<p>{backtick}[]<code class="o_inline_code" data-oe-zws-empty-inline></code></p>`
now we delete forward again it will delete the inline block which
validate the following condition [1] which forces a deleteForward in the
parent element at offset one which is basically here
`<p>{backtick}[]<p>` which now will reach this part of code [2] and the
`findNode` will return a node outside the editable because we didn't
specify the `root` element as a stopping condition.
Solution:
=========
- First we fix the spec of the inline code block which should do nothing
in case there is no content inside it.
- We add the root as stopping condition while generating the path.
[1]: https://github.com/odoo/odoo/blob/16.0/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L125-L143
[2]: https://github.com/odoo/odoo/blob/d0828eecf60f7c8622d6875b8651eb663bc7d695/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L214-L241
opw-4254182
Forward-Port-Of: odoo/odoo#183567The project's visibility should be tracked in the chatter of the project, but not in the tasks chatter. This PR will set the tracking of the "project_privacy_visibility" field to False, so that it is no longer displayed in the tasks chatter. task-4210181 Forward-Port-Of: odoo/odoo#181873
Original PR description
The project's visibility should be tracked in the chatter of the project, but not in the tasks chatter. This PR will set the tracking of the "project_privacy_visibility" field to False, so that it is no longer displayed in the tasks chatter. task-4210181 Forward-Port-Of: odoo/odoo#181873
For the longest time, the base `ModelConverter` (and `ModelsConverter`) have added a group around their regex. That was (apparently) never useful but Werkzeug didn't care. Except, it turns out, Werkzeug 2.2 specifically, which is the one we require for Python 3.11, because it's the one bundled in Debian Bookworm. In this version and this version only werkzeug gets tripped up by our extra group, and doubles up the parameters. This makes it very hard to see as: - we need a version which u
Original PR description
For the longest time, the base `ModelConverter` (and `ModelsConverter`) have added a group around their regex. That was (apparently) never useful but Werkzeug didn't care. Except, it turns out,…
For the longest time, the base `ModelConverter` (and `ModelsConverter`) have added a group around their regex. That was (apparently) never useful but Werkzeug didn't care.
Except, it turns out, Werkzeug 2.2 specifically, which is the one we require for Python 3.11, because it's the one bundled in Debian Bookworm.
In this version and this version only werkzeug gets tripped up by our extra group, and doubles up the parameters. This makes it very hard to see as:
- we need a version which uses at least two converters, at least one of which is `model` or `models` in non-last position
- we need to realise that the latter converter gets a copy of the former
The first one is relatively common (70 cases in community, of which 48 use multiple `model` or `models`), however the part where it has to be test and noticed is a lot less likely as we don't routinely test this configuration. Unless somebody happens to use 3.11 locally and follow the `requirements.txt` when installing odoo...
Fixes runbot error 73290
Repro case:
- install tox
- create a file `tox.ini` containing:
```ini
[tox]
requires = tox >= 4
env_list = werkzeug{016,10,21,22,23,3}
[testenv]
deps =
pytest
werkzeug016: werkzeug~=0.16.0
werkzeug10: werkzeug~=1.0.0
werkzeug21: werkzeug~=2.1.0
werkzeug22: werkzeug~=2.2.0
werkzeug23: werkzeug~=2.3.0
werkzeug3: werkzeug~=3.0
commands = pytest app.py
```
- create a file `app.py` containing:
```python
import json
import pytest
from werkzeug.wrappers import Response
from werkzeug.test import Client
from werkzeug.routing import Map, Rule, BaseConverter
class ModelConverter(BaseConverter):
regex = r'([0-9]+)'
def to_python(self, value: str) -> int:
return int(value)
class ModelsConverter(BaseConverter):
regex = r'([0-9,]+)'
def to_python(self, value: str) -> list[int]:
return [int(v) for v in value.split(',')]
url_map = Map(
[
Rule("/id/<id:a>"),
Rule("/id/<id:a>/<id:b>"),
Rule("/ids/<ids:as>"),
Rule("/ids/<ids:as>/<id:b>"),
],
strict_slashes=False,
converters={
'id': ModelConverter,
'ids': ModelsConverter,
}
)
def application(environ, start_response):
urls = url_map.bind_to_environ(environ)
endpoint, args = urls.match()
start_response('200 OK', [('Content-Type', 'text/plain')])
return [json.dumps(args)]
@pytest.mark.parametrize('url,res', [
("/id/1", {'a': 1}),
("/id/1/2", {'a': 1, 'b': 2}),
("/ids/1,2,3", {"as": [1, 2, 3]}),
("/ids/1,2,3/4", {"as": [1, 2, 3], "b": 4}),
])
def test_routing(url, res):
c = Client(application, Response)
r = c.get(url)
assert json.loads(r.get_data()) == res
```
- run `tox`
- observe that Werkzeug 2.2 and that version only blows up on cases 2 and 4
Removing the parenthesis inside the regexes fixes the issue.
Forward-Port-Of: odoo/odoo#184277Currently we search for the 'us' chart template but we should search for the 'generic_coa' instead. This commit corrects it. task-None Forward-Port-Of: odoo/enterprise#71908
Original PR description
Currently we search for the 'us' chart template but we should search for the 'generic_coa' instead. This commit corrects it. task-None Forward-Port-Of: odoo/enterprise#71908
Spotted by runbot in master by the `self-in-iter` semgrep check. Forward-Port-Of: odoo/enterprise#72335
Original PR description
Spotted by runbot in master by the `self-in-iter` semgrep check. Forward-Port-Of: odoo/enterprise#72335
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amount
Original PR description
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amounts which are not supposed to appear as the report only deals with positive values, and also ensured the discounts on the move lines are computed correctly. task-3992046 Forward-Port-Of: odoo/enterprise#72271 Forward-Port-Of: odoo/enterprise#65074
Steps to reproduce the bug: - Create two Storable product: - “P1” -> product category A - “P2” -> product category B - Create a quality point: - picking type: receipt - product category: Cat A & Cat B - Measure: by quantity - Create a second quality point: - picking type: receipt - product category: Cat A - Measure: by quantity - Create a receipt of one unit of P1 and P2 - Confirm Problem: Four quality checks are created instead of three bec
Original PR description
Steps to reproduce the bug:
- Create two Storable product:
- “P1” -> product category A
- “P2” -> product category B
- Create a quality point:
- picking type: receipt
- product category: Cat A & Cat B
- Measure: by quantity
- Create a second quality point:
- picking type: receipt
- product category: Cat A
- Measure: by quantity
- Create a receipt of one unit of P1 and P2
- Confirm
Problem:
Four quality checks are created instead of three because we check if the quality point corresponds to the picking type and if the quality point has no product selected. However, we don't verify if a product category is also not set.
opw-4240859
Forward-Port-Of: odoo/enterprise#71453To reproduce: ============= - log as admin and create a template on sign - give a user with **User : Own templates** authorization to the template - log as the user and try to use layout (from 3 dots in kanban view) -> access error Problem: ======== when duplicating the template we copy the original template, as the user does not have enough rights it leads to an access error Solution: ========= perform the copy as `sudo`, as the template won't be visible for the user if he is not
Original PR description
To reproduce: ============= - log as admin and create a template on sign - give a user with **User : Own templates** authorization to the template - log as the user and try to use layout (from 3 dots in kanban view) -> access error Problem: ======== when duplicating the template we copy the original template, as the user does not have enough rights it leads to an access error Solution: ========= perform the copy as `sudo`, as the template won't be visible for the user if he is not authorized to see it. opw-4166973 Forward-Port-Of: odoo/enterprise#70496
There is a bug with traceback while going to "Accounting / Configuration / Settings" with "Spanish (Latin America)" language selected on user config (install l10n_ar_edi module and take position on company "(AR) Responsable Inscripto"). This pr fixes it. The bug was introduced on this pr https://github.com/odoo/enterprise/pull/71027 . Bug with traceback: UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) OwlError: An
Original PR description
There is a bug with traceback while going to "Accounting / Configuration / Settings" with "Spanish (Latin America)" language selected on user config (install l10n_ar_edi module and take position on…
There is a bug with traceback while going to "Accounting / Configuration / Settings" with "Spanish (Latin America)" language selected on user config (install l10n_ar_edi module and take position on company "(AR) Responsable Inscripto"). This pr fixes it. The bug was introduced on this pr https://github.com/odoo/enterprise/pull/71027 .
Bug with traceback:
UncaughtPromiseError > OwlError
Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property)
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
Error: An error occured in the owl lifecycle (see this Error's "cause" property)
at handleError (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:916:101)
at App.handleError (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1548:29)
at Fiber._render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:941:19)
at Fiber.render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:939:6)
at ComponentNode.initiateRender (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1007:47)
Caused by: EvalError: Can not parse python expression: (bool(“l10n_ar_afip_ws_crt”))
Error: Invalid expression
EvalError: Can not parse python expression: (bool(“l10n_ar_afip_ws_crt”))
Error: Invalid expression
at evaluateExpr (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:3050:128)
at SettingsFormRenderer.evaluateBooleanExpr (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:3054:8)
at SettingsFormRenderer.slot533 (eval at compile (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1502:374), <anonymous>:9209:26)
at callSlot (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1108:25)
at SearchableSetting.template (eval at compile (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1502:374), <anonymous>:56:13)
at Fiber._render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:940:96)
at Fiber.render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:939:6)
at ComponentNode.initiateRender (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1007:47)
Ticket Adhoc side: 81698
Task latam side: 1279
Forward-Port-Of: odoo/enterprise#72155Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#71664 Forward-Port-Of: odoo/enterprise#69552
Original PR description
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#71664 Forward-Port-Of: odoo/enterprise#69552
…ifferent trees Add a field at the end of the "left" subgroup and remove the "right" subgroup. ```xml <form> <group> <group> <field name="display_name" /> [ADD A FIELD] </group> [ REMOVE THIS GROUP <group> </group> ] </group> </form> ``` Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between. We were left with the inheriting vi
Original PR description
…ifferent trees
Add a field at the end of the "left" subgroup and remove the "right" subgroup.
```xml
<form>
<group>
<group>
<field name="display_name" />
[ADD A FIELD]
</group>
[ REMOVE THIS GROUP
<group>
</group>
]
</group>
</form>
```
Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between.
We were left with the inheriting view:
```xml
<xpath expr="[..]/group[2]" position="replace">
<field name="added_field" />
</xpath>
```
After this commit, this flow works and the two operations are independent.
part of task-4207793
Forward-Port-Of: odoo/enterprise#71969
Forward-Port-Of: odoo/enterprise#71289Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72037 Forward-Port-Of: odoo/enterprise#71459
Original PR description
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72037 Forward-Port-Of: odoo/enterprise#71459
Before this commit, it was possible to fill two date fields in two different date formats in the same document. This happened because the date format was dependent on the location of the user who is signing. After this commit, date fields will be auto-filled by a fixed date format, that format depends on the language of the company's partner. Task: 3930358 Forward-Port-Of: odoo/enterprise#64591
Original PR description
Before this commit, it was possible to fill two date fields in two different date formats in the same document. This happened because the date format was dependent on the location of the user who is signing. After this commit, date fields will be auto-filled by a fixed date format, that format depends on the language of the company's partner. Task: 3930358 Forward-Port-Of: odoo/enterprise#64591