Thursday, October 14, 2021
26 changes · master
Resolved issues and error corrections
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
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
**[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