Thursday, October 14, 2021
29 changes · master
Enhancements to existing features
Odoo now limits repeated incoming emails from the same sender within a configurable time window, helping prevent endless back-and-forth with auto-reply systems. This reduces mail clutter and system load while preserving normal replies with higher thresholds for active conversations.
Original PR description
Purpose ======= Some situations can cause emails loop. In example, if a auto-replier is set and send email to the catchall email address, Odoo will respond "You can not contact the catchall email…
Purpose ======= Some situations can cause emails loop. In example, if a auto-replier is set and send email to the catchall email address, Odoo will respond "You can not contact the catchall email directly". And the auto-replier will send again an email, etc. Specifications ============== To solve this issues, we add 3 system parameters - <mail.incoming.limit.period>, 60 minutes by default - <mail.incoming.limit.alias>, 5 by default - <mail.incoming.limit.replies>, 90 by default So, when we receive an email, 3 situations can occur. 1. The email is sent to an alias and a record will be created. In that case, we look on the last record created <mail.incoming.limit.period> minutes ago. If we overcome <mail.incoming.limit.alias> the email is ignored. 2. The email is sent to an existing mail thread. In that case, the limit is set with the <mail.incoming.limit.replies> parameters (so we can have a bigger limit for the replies than for the alias). 3. The email is not routed. In that case we create a unrouted message and the alias limit is used. Task 2294034
The forum question page has been made clearer and easier to manage, with better page naming, smarter tooltips, and warnings when users try to submit empty questions or answers. Moderators also get direct actions to validate flagged questions or mark them as offensive from the question page, reducing extra navigation.
Original PR description
purpose Misc improvements on Forum specifications - Change title of new question page from 'new_question' to 'New Question'. - Display tooltip "only one answer per question is allowed" only for question- answer type of forum. - Prevent the user with the warning popup to submit his question or answer without description . - Once the question is flagged, add two options for it: 'Validate' and 'Mark as Offensive'. So, directly can validate or submit with flagged reason from question page. - Add a new tour for flag a question and show how to validate or submit flagged reason of question from question page. task-2167561 Closes #45352
Resolved issues and error corrections
This fixes cases where a previously opened action could reuse outdated session context after changes such as switching companies. Users should now see screens and data filtered according to their current user settings after a browser reload.
Original PR description
the context of an action stored in session overrides user context 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
Miscellaneous changes
Description of the issue/feature this PR addresses: Somehow we missed the FFI prefix. 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#78004
Original PR description
Description of the issue/feature this PR addresses: Somehow we missed the FFI prefix. 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#78004
The Project Gantt view now uses the start date as its default ordering when loading data. This makes project timelines appear in a more natural and predictable sequence for users reviewing scheduled work.
Original PR description
This PR purpose is to ensure that the rpc call of the project gantt view is using the start date as default sort order. task-2516896
**[FIX] stock: avoid attempt to create the same lot** > How to reproduce: > - Create a product tracked by lot; > - Create two receipts for this product; > - Use the same lot name in the two receipts; > - Try to validate the two receipts in the same time > => `ValidationError` will trigger in the `_check_unique_lot` constrain of the production lot. > > task-2646107 **[FIX] product_expiry: lot expiration_date** > This commit adresses to two issues: > > Since 0c83542, th
Original PR description
**[FIX] stock: avoid attempt to create the same lot** > How to reproduce: > - Create a product tracked by lot; > - Create two receipts for this product; > - Use the same lot name in the two receipts;…
**[FIX] stock: avoid attempt to create the same lot** > How to reproduce: > - Create a product tracked by lot; > - Create two receipts for this product; > - Use the same lot name in the two receipts; > - Try to validate the two receipts in the same time > => `ValidationError` will trigger in the `_check_unique_lot` constrain of the production lot. > > task-2646107 **[FIX] product_expiry: lot expiration_date** > This commit adresses to two issues: > > Since 0c83542, the move line's `expiration_date` set by the user is always overrided at the creation of the move which means the user has to modify it after the move was created. > > To fix that, the compute doesn't override the `expiration_date` if there is already one set. > Therefore, the onchange on the product who was removed is re-added to force to recompute the `expiration_date` if the move line's product is changed and it has already an `expiration_date` set. Forward-Port-Of: odoo/odoo#77411 Forward-Port-Of: odoo/odoo#76847
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78281
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78281
... and other errors found during testing See individual commits for details Forward-Port-Of: odoo/odoo#78012
Original PR description
... and other errors found during testing See individual commits for details Forward-Port-Of: odoo/odoo#78012
PURPOSE When m2o has can_create=false and user try to search something that doesn't exist then it should show 'No results to show' in m2o autocomplete. SPEC If user can not create m2o record and if user searches in m2o that doesn't exist in m2o model then it should display 'No results to show' item in m2o autocomplete. TASK 2376435 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#63673
Original PR description
PURPOSE When m2o has can_create=false and user try to search something that doesn't exist then it should show 'No results to show' in m2o autocomplete. SPEC If user can not create m2o record and if user searches in m2o that doesn't exist in m2o model then it should display 'No results to show' item in m2o autocomplete. TASK 2376435 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#63673
Steps to follow - Set the thousands_sep of the current lang to an empty string or null - Create a report -> The thousand separator from the system locale will be used instead to format numbers opw-2507441 Forward-Port-Of: odoo/odoo#75868
Original PR description
Steps to follow - Set the thousands_sep of the current lang to an empty string or null - Create a report -> The thousand separator from the system locale will be used instead to format numbers opw-2507441 Forward-Port-Of: odoo/odoo#75868
**Description of the issue/feature this PR addresses:** Fields removed from l10n_latam: * l10n_latam_amount_untaxed * l10n_latam_tax_ids * l10n_latam_price_unit * l10n_latam_price_subtotal * l10n_latam_price_net Methods removed from l10n_latam: * compute_l10n_latam_prices_and_taxes * compute_l10n_latam_amount_and_taxes * _compute_invoice_taxes_by_group Move the removed methods to l10n_ar and l10n_cl and now it returns a dictionary with the required values. Also, adapt t
Original PR description
**Description of the issue/feature this PR addresses:** Fields removed from l10n_latam: * l10n_latam_amount_untaxed * l10n_latam_tax_ids * l10n_latam_price_unit * l10n_latam_price_subtotal * l10n_latam_price_net Methods removed from l10n_latam: * compute_l10n_latam_prices_and_taxes * compute_l10n_latam_amount_and_taxes * _compute_invoice_taxes_by_group Move the removed methods to l10n_ar and l10n_cl and now it returns a dictionary with the required values. Also, adapt the invoices reports to get the required values from the new methods for each localization. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77961
When the editor was inside a table in the odoo view HTML, The KeyDown detected that the selection was inside a table and was trying to add a row bellow the table outside the editor. task-2601451 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78132
Original PR description
When the editor was inside a table in the odoo view HTML, The KeyDown detected that the selection was inside a table and was trying to add a row bellow the table outside the editor. task-2601451 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78132
Before this commit An action retrieved from the session storage may not take into account changes in the user context because the user context is duplicated in the action context. When the user context changes i.e. through the switch company menu (allowed_company_ids) and the browser reloads, the action service will make the action context concatening the new user context with the context of the action stored in the session storage, which has still values from the previous user context.
Original PR description
Before this commit An action retrieved from the session storage may not take into account changes in the user context because the user context is duplicated in the action context. When the user context changes i.e. through the switch company menu (allowed_company_ids) and the browser reloads, the action service will make the action context concatening the new user context with the context of the action stored in the session storage, which has still values from the previous user context. After this commit The makeContext function can now take an initial evaluation context. This is then used in the action service in order to make use of the user context when the action context is generated but without appending it into the action one. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78381
The Gulf Cooperation Council country group is missing the kingdom of Saudi Arabia Members are : Bahrain, Kuwait, Oman, Qatar, Saudi Arabia and United Arab Emirates https://en.wikipedia.org/wiki/Gulf_Cooperation_Council -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78353
Original PR description
The Gulf Cooperation Council country group is missing the kingdom of Saudi Arabia Members are : Bahrain, Kuwait, Oman, Qatar, Saudi Arabia and United Arab Emirates https://en.wikipedia.org/wiki/Gulf_Cooperation_Council -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78353
Previously, when cancelling an Ingenico transaction, the cancellation was considered done from the POS' point of view even though it hadn't actually finished on the terminal yet. Starting a new transaction from the POS meant it would fail and the POS and terminal's states would get out of sync. In an enterprise PR for the pos_iot module, a fix was made so the cancellation request is only considered done when the terminal has confirmed that. In the case of pressing cancel on a payment
Original PR description
Previously, when cancelling an Ingenico transaction, the cancellation was considered done from the POS' point of view even though it hadn't actually finished on the terminal yet. Starting a new…
Previously, when cancelling an Ingenico transaction, the cancellation was considered done from the POS' point of view even though it hadn't actually finished on the terminal yet. Starting a new transaction from the POS meant it would fail and the POS and terminal's states would get out of sync. In an enterprise PR for the pos_iot module, a fix was made so the cancellation request is only considered done when the terminal has confirmed that. In the case of pressing cancel on a payment line, this means that the button will block and remain in a loading state with a spinner until the operation finishes. After this the user can press the retry button the payment line. There are two other workflows where waiting for the cancel operation to finish wasn't done until now, and that's what this PR is for. The first is when a transaction was requested and the back button was pressed in the UI. This cancels the active transactions. If you wait a while after pressing the back button, the UI will be notified when the cancellation finishes, and the payment line's state will be updated in the local db, even if it's not visible on screen. When you go back to the payment screen, you'll be able to retry the transaction again. However, if after pressing the back button you immediately go back to the payment screen, you'll see the spinner of the wait for the cancellation, but it would never update. That's because while the local db gets updated when the cancellation finishes, the payment screen lines didn't get refreshed. Hence a call was added to `stop_electronic_payment` that re-renders the payment lines (if we are present on the payment screen) once the cancellation finishes. In this way, the payment state in the UI will correctly update. The second case is when a transaction is requested and the user deletes the payment line. This used to happen immediately without waiting for anything. This PR changes that so the line goes to the `waitingCancel` state instead, and will only be deleted once the operation finishes. If there's nothing to be cancelled, the line will get deleted immediately like before. opw-2525010 Forward-Port-Of: odoo/odoo#78365 Forward-Port-Of: odoo/odoo#77585
If a transaction request is sent to the terminal and followed by a cancellation request, the cancellation request will get a cancellation response. After that, the transaction response will be returned and it will have the transaction result "Error". If you leave several seconds between each of these operations, no errors will occur. So the "normal" order of events when you start a transaction, cancel it, and start a new one is: T1: TransactionRequest T1: CancelRequest T1: CancelRes
Original PR description
If a transaction request is sent to the terminal and followed by a cancellation request, the cancellation request will get a cancellation response. After that, the transaction response will be…
If a transaction request is sent to the terminal and followed by a cancellation request, the cancellation request will get a cancellation response. After that, the transaction response will be returned and it will have the transaction result "Error". If you leave several seconds between each of these operations, no errors will occur. So the "normal" order of events when you start a transaction, cancel it, and start a new one is: T1: TransactionRequest T1: CancelRequest T1: CancelResponse T1: TransactionResponse: Error T2: TransactionRequest T2: CancelRequest T2: CancelResponse T2: TransactionResponse: Error If you quickly start a new transaction after cancelling, the order is different: T1: TransactionRequest T1: CancelRequest T1: CancelResponse T2: TransactionRequest T1: TransactionResponse: Error T2: TransactionResponse: Error In other words, starting the second transaction too quickly results in it getting cancelled as well. The TLV protocol defines a TerminalState field (section 4.2.2) that describes whether a cancellation or a new transaction is possible. This hasn't been implemented in the IngenicoDriver, but I did so as a test. When the CancellationResponse is returned, the "TransactionRequestPossible" flag (bit 1 in TerminalState) is still false. That's why requesting a new transaction at that point fails. It's only when the TransactionResponse is returned, indicating the transaction has finished, that the TransactionRequestPossible flag becomes true again. I've experimented with several strategies to take the above into account. The first was to try to prevent the problem at the level of the IngenicoDriver, so if a cancellation was done and a new transaction requested right after, it would wait until the old transaction had finished and the new one was possible. This worked on the IngenicoDriver level, but caused 2 problems on the POS side. The first is that there's currently a 6 second timeout hard-coded on the POS side, which would get triggered because the operation took too long as a result. The time when the TransactionResponse is returned appears linked to the keepalive interval (hard-coded to 5 seconds in the terminal). In theory this could be worked around by increasing the timeout on the POS side. Another issue is that the POS has no way of distinguishing the TransactionResponses from the two different transactions. The transaction id (or cid in the POS) remains the same. When you start the second transaction in the POS, it'll wait for a response. If that response has the error flag set, it'll assume the second transaction failed. But if due to timing the response from the first transaction arrives (which got cancelled and will also have the error flag set), it'll assume the second transaction failed and will report that to the user. It's easy to propagate the TerminalState flags from the driver to the POS, but it's not sufficient information for the POS to make a good decision because it can't distinguish between the transactions. Changing transaction id in the POS after cancelling a transaction seems like it could be its own recipe for further synchronization issues. So the cleanest way to deal with this seems to be to prevent starting a new transaction from the POS UI side until it's certain the previous one is finished. In the previous logic, the cancellation was considered finished by the UI once the Stage field in the event data became blank. The Stage field is the transaction stage from the TLV spec (section 4.4 .3). This field is for indicating which stage is displayed to the user on the terminal. If we send a cancellation to the terminal, that stage indeed becomes blank, but this doesn't mean the transaction is finished. The only happens when a TransactionResponse is returned that has the error field set. So the solution I settled on here is to ignore the blank Stage field and only consider the cancellation done when the stage is finished or the error field is set. In theory we could also take into account the TerminalState at this point if it were implemented in the IngenicoDriver, but that doesn't seem to have added value at this point. opw-2525010 Forward-Port-Of: odoo/enterprise#21693 Forward-Port-Of: odoo/enterprise#21342
This commit includes the following changes: [FIX] selection_inputs: make the id unique [FIX] evaluation: correctly handle cells in error state [FIX] tests: destroy top bar parent component [REF] cells: use OO API to narrow the type of a cell [REF] tests: remove helper component GridParent [FIX] autofill: don't move tootip when scrolling [IMP] demo: make demo page responsive [FIX] sheet: getSheetIdByName should not be case-sensitive [FIX] spreadsheet: Open the sheet at the first positi
Original PR description
This commit includes the following changes: [FIX] selection_inputs: make the id unique [FIX] evaluation: correctly handle cells in error state [FIX] tests: destroy top bar parent component [REF] cells: use OO API to narrow the type of a cell [REF] tests: remove helper component GridParent [FIX] autofill: don't move tootip when scrolling [IMP] demo: make demo page responsive [FIX] sheet: getSheetIdByName should not be case-sensitive [FIX] spreadsheet: Open the sheet at the first position [FIX] chart: handle #REF dataset [config] add package-lock.json [FIX] menus: disable text selection [FIX] config: update Typescript, jest and owl Forward-Port-Of: odoo/enterprise#21620
In the test tour `test_inventory_adjustment_tracked_product`, makes triggers more specific to avoid concurrency issues by triggering them too quickly. Forward-Port-Of: odoo/enterprise#21409
Original PR description
In the test tour `test_inventory_adjustment_tracked_product`, makes triggers more specific to avoid concurrency issues by triggering them too quickly. Forward-Port-Of: odoo/enterprise#21409
…ncy if no rate It can happen that we have a transaction in a foreign currency without having any rate provided. In this case, we should not raise an error directly, but rather look for the corresponding amount in the journal currency instead, which would allow to import the file anyway. opw-2632582 Forward-Port-Of: odoo/enterprise#21668 Forward-Port-Of: odoo/enterprise#21475
Original PR description
…ncy if no rate It can happen that we have a transaction in a foreign currency without having any rate provided. In this case, we should not raise an error directly, but rather look for the corresponding amount in the journal currency instead, which would allow to import the file anyway. opw-2632582 Forward-Port-Of: odoo/enterprise#21668 Forward-Port-Of: odoo/enterprise#21475
Some of the information on the employee's form view was not restricted enough and resulted in an access right error. This commit adds some groups rules to make sure it does not happen. TaskId-2666790 Forward-Port-Of: odoo/enterprise#21605
Original PR description
Some of the information on the employee's form view was not restricted enough and resulted in an access right error. This commit adds some groups rules to make sure it does not happen. TaskId-2666790 Forward-Port-Of: odoo/enterprise#21605
PURPOSE We do not check access on document and we allow user to toggle favorite on document always, even if user do not have access on document still user can toggle favorite. SPEC toggle_favorited method should allow user to toggle document even if user do not have access on document. TASK 2622992 Forward-Port-Of: odoo/enterprise#20307
Original PR description
PURPOSE We do not check access on document and we allow user to toggle favorite on document always, even if user do not have access on document still user can toggle favorite. SPEC toggle_favorited method should allow user to toggle document even if user do not have access on document. TASK 2622992 Forward-Port-Of: odoo/enterprise#20307
Enterprise part of odoo/odoo#78012 See individual commits for details Forward-Port-Of: odoo/enterprise#21524
Original PR description
Enterprise part of odoo/odoo#78012 See individual commits for details Forward-Port-Of: odoo/enterprise#21524
https://github.com/odoo/enterprise/commit/df24931792a9818faaf6c8ed3277a3e5d2a7f980 fixed the corresponding domain for the abridged report ; but the main one was left untouched. Forward-Port-Of: odoo/enterprise#21652
Original PR description
https://github.com/odoo/enterprise/commit/df24931792a9818faaf6c8ed3277a3e5d2a7f980 fixed the corresponding domain for the abridged report ; but the main one was left untouched. Forward-Port-Of: odoo/enterprise#21652
Steps to reproduce the bug: - Let's consider a product P with cost = 50€ - Create a vendor bill with P and validate it - Create an other vendor bill VB and add a line L with price unit = 100€ and a tax T - In the Label field of L, add P and click outside of the field Bug: The subtotal of L was still 100€ (but the price unit was 50€) and the amount_total was not recomputed. When saving VB, the price unit of L was changed to 100€ opw:2657443 Forward-Port-Of: odoo/enterprise#21519
Original PR description
Steps to reproduce the bug: - Let's consider a product P with cost = 50€ - Create a vendor bill with P and validate it - Create an other vendor bill VB and add a line L with price unit = 100€ and a tax T - In the Label field of L, add P and click outside of the field Bug: The subtotal of L was still 100€ (but the price unit was 50€) and the amount_total was not recomputed. When saving VB, the price unit of L was changed to 100€ opw:2657443 Forward-Port-Of: odoo/enterprise#21519
Steps to reproduce the bug: - Let's consider two companies A, B - Create a vendor bill in A for a partner P with a line L - Set an account on L and write XYZ in the label field of L - Go to company B and create a vendor bill for P - Add a line and set XYZ in the label field Bug: A multi company access error was raised opw:2661099 Forward-Port-Of: odoo/enterprise#21585 Forward-Port-Of: odoo/enterprise#21529
Original PR description
Steps to reproduce the bug: - Let's consider two companies A, B - Create a vendor bill in A for a partner P with a line L - Set an account on L and write XYZ in the label field of L - Go to company B and create a vendor bill for P - Add a line and set XYZ in the label field Bug: A multi company access error was raised opw:2661099 Forward-Port-Of: odoo/enterprise#21585 Forward-Port-Of: odoo/enterprise#21529
In follow-up reports, reversed invoices pdf's can be in attachment of follow up mails. It is confusing because these invoices do not show in the mail but their pdf's is attached. Before, these attachments were based on the "unpaid_invoices" of the partner which include reversed invoices. Now, this fix will not include invoices with a "payment_state" as 'reversed' when computing "unpaid_invoices". opw-2606629 Forward-Port-Of: odoo/enterprise#21388 Forward-Port-Of: odoo/enterprise#20269
Original PR description
In follow-up reports, reversed invoices pdf's can be in attachment of follow up mails. It is confusing because these invoices do not show in the mail but their pdf's is attached. Before, these attachments were based on the "unpaid_invoices" of the partner which include reversed invoices. Now, this fix will not include invoices with a "payment_state" as 'reversed' when computing "unpaid_invoices". opw-2606629 Forward-Port-Of: odoo/enterprise#21388 Forward-Port-Of: odoo/enterprise#20269
Change the way the amounts (monetary) are checked against 0 to use the company currency helper to do so, in order to avoid adding lines that are 0 after formatting to the entry. Forward-Port-Of: odoo/enterprise#21610
Original PR description
Change the way the amounts (monetary) are checked against 0 to use the company currency helper to do so, in order to avoid adding lines that are 0 after formatting to the entry. Forward-Port-Of: odoo/enterprise#21610
Terms in o-spreadsheet templates were not translated because the translation function from odoo was not correctly set in the o-spreadsheet env. Hence the default translation function of o-spreadsheet (which does nothing) was used instead. Note: terms were correctly extracted, so there are available translations. Also fix the template dialog title which was not translatable and update the .pot file. It seems that previous changes forgot to do it. Forward-Port-Of: odoo/enterprise#21557
Original PR description
Terms in o-spreadsheet templates were not translated because the translation function from odoo was not correctly set in the o-spreadsheet env. Hence the default translation function of o-spreadsheet (which does nothing) was used instead. Note: terms were correctly extracted, so there are available translations. Also fix the template dialog title which was not translatable and update the .pot file. It seems that previous changes forgot to do it. Forward-Port-Of: odoo/enterprise#21557 Forward-Port-Of: odoo/enterprise#21540
Testing the PE edi in saas-14.5, we saw that the markupsafe object was not well digested by the b64encode. Furthermore an error in the code prevented the error to be shown when there was an error in the response. Forward-Port-Of: odoo/enterprise#21332
Original PR description
Testing the PE edi in saas-14.5, we saw that the markupsafe object was not well digested by the b64encode. Furthermore an error in the code prevented the error to be shown when there was an error in the response. Forward-Port-Of: odoo/enterprise#21332