Wednesday, November 17, 2021
27 changes · master
Enhancements to existing features
Website editors can now add a dynamic block that automatically displays upcoming events. The block replaces the older event snippet and adds filtering by multiple tags, helping visitors see the most relevant events more easily.
Original PR description
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
The online course pages now use placeholder wording that looks more clearly like sample content, reducing the chance that users mistake it for real course text. Default course examples also show a "Sample" ribbon, and placeholder text is lighter and disappears when users start editing.
Original PR description
Purpose ======= Make placeholder look more like sample text to avoid users confusing it with actual text, add "Sample" ribbon to default course context to avoid confusing some users. Specifications ============= Change default placeholder text, add css rule for placeholders in website_slide to make the colour lighter and disappear on focus. PR: /pull/78845 Task-2674361
Resolved issues and error corrections
Approved expense reports now prevent changes to their expense lines. This helps protect validated accounting information from accidental or unauthorized edits after manager approval.
Original PR description
Expected Behaviour When creating a journal entry for an expense, the journal shouldn't be editable once it has been submitted for approval. Observed Behaviour Even when the journal entry has been validated by the manager, the list of expenses is still editable, which can cause serious trouble. Reproducibility This bug can be reproduced following these steps: - Create a new expense - Create the related journal entry (Create report) - Submit the report for approval - Validate the report - Try to edit the expenses list Problem Root Cause As it can be seen in the PR, this issue came from the fact the expense list isn't in read-only mode Related Issue(s) opw-2659436 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
Features or functions removed from Odoo
This change removes obsolete internal code that was no longer being used. It helps keep the system easier to maintain without changing day-to-day business workflows.
Original PR description
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: This PR addresses issue #68761 for version 14.0. The issue describes a bug that results in a field not being automatically updated. Current behavior before PR: HR Presence State Display field not automatically updated unless officer manually does some actions. Desired behavior after PR is merged: HR Presence State Display field will be automatically updated and visible for employees. -- I confirm I have signed the CLA and rea
Original PR description
Description of the issue/feature this PR addresses: This PR addresses issue #68761 for version 14.0. The issue describes a bug that results in a field not being automatically updated. Current behavior before PR: HR Presence State Display field not automatically updated unless officer manually does some actions. Desired behavior after PR is merged: HR Presence State Display field will be automatically updated and visible for employees. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79837 Forward-Port-Of: odoo/odoo#68766
In multi steps configurations, the additional products of a MO could be missing in the associated picking To reproduce the issue: (Use demo data) 1. In Settings, enable "Multi-Step Routes" 2. Update the current warehouse: - Manufacture: 2 steps 3. Create a MO for product "Table Top" 4. Edit the MO: - Add 1 x Screw in the components 5. Confirm the MO 6. Open the generated Picking Error: The operations only contains one line for "Wood Panel". There should be a second line
Original PR description
In multi steps configurations, the additional products of a MO could be
missing in the associated picking
To reproduce the issue:
(Use demo data)
1. In Settings, enable "Multi-Step Routes"
2. Update the current warehouse:
- Manufacture: 2 steps
3. Create a MO for product "Table Top"
4. Edit the MO:
- Add 1 x Screw in the components
5. Confirm the MO
6. Open the generated Picking
Error: The operations only contains one line for "Wood Panel". There
should be a second line for the "Screw"
When adding the new component, a new stock move is created but the
latter does not have any `group_id` defined. This is the reason why the
generated picking does not include this stock move.
OPW-2671995
Forward-Port-Of: odoo/odoo#79868
Forward-Port-Of: odoo/odoo#79759Forward-Port-Of: odoo/odoo#79874
Original PR description
Forward-Port-Of: odoo/odoo#79874
Before this commit, when exporting the FEC report, we were using the account journal name in the initial language set. As it could be confusing for the French administration to see names in a foreign language, we should use the user language instead to allow the export of FEC report in French even if another default language was used. Description of the issue/feature this PR addresses: opw-2649805 Current behavior before PR: Desired behavior after PR is merged: -- I confir
Original PR description
Before this commit, when exporting the FEC report, we were using the account journal name in the initial language set. As it could be confusing for the French administration to see names in a foreign language, we should use the user language instead to allow the export of FEC report in French even if another default language was used. Description of the issue/feature this PR addresses: opw-2649805 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#79679
In case of m event being removed by a change in recurrence further change is then only applied on the existing events and not all past events. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79872
Original PR description
In case of m event being removed by a change in recurrence further change is then only applied on the existing events and not all past events. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79872
Purpose ======= Since v15, the time to import records in Odoo is much slower than in v14. With a profiling, we know that the cause is `fields_get`. Indeed, this method is heavy and call many times (#rows * #columns * ~#batches). So the import time (in seconds) is; ``` Batch size | v14 | v15 | v15 fix -------------------------------- 2000 | 7 | 20 | 14 200 | 11 | 48 | 15 20 | 17 | 423 | 23 ``` We can see that just by calling `._fields.g
Original PR description
Purpose ======= Since v15, the time to import records in Odoo is much slower than in v14. With a profiling, we know that the cause is `fields_get`. Indeed, this method is heavy and call many times (#rows * #columns * ~#batches). So the import time (in seconds) is; ``` Batch size | v14 | v15 | v15 fix -------------------------------- 2000 | 7 | 20 | 14 200 | 11 | 48 | 15 20 | 17 | 423 | 23 ``` We can see that just by calling `._fields.get` instead of `fields_get` we gain a lot of time. The reason for that is `fields_get` just read in a python dictionary (which is really really fast), while `fields_get` checks the access right, get the description of each fields (which might make SQL queries to retrieve translation, etc). Task-2687407 Forward-Port-Of: odoo/odoo#79600
We should call view portal_rating.rating_widget_stars_static instead of portal_rating.rating_widget_stars_static_compressed. Description of the issue/feature this PR addresses: opw-2687483 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#79803
Original PR description
We should call view portal_rating.rating_widget_stars_static instead of portal_rating.rating_widget_stars_static_compressed. Description of the issue/feature this PR addresses: opw-2687483 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#79803
This fix improves the behavior in notebooks by showing the correct pane before scrolling. The scrollTo util has been improved to remove duplicate lines and handle multiple situations (0, one or more scrollables). A new util is added to display the target pane when a notebook is present. Tests haven been written to test such behaviors. Description of the issue/feature this PR addresses: When using a link to navigate to an anchor in a notebook, the scrollTo function crash because it coul
Original PR description
This fix improves the behavior in notebooks by showing the correct pane before scrolling. The scrollTo util has been improved to remove duplicate lines and handle multiple situations (0, one or more scrollables). A new util is added to display the target pane when a notebook is present. Tests haven been written to test such behaviors. Description of the issue/feature this PR addresses: When using a link to navigate to an anchor in a notebook, the scrollTo function crash because it couldn't find any scrollable. Current behavior before PR: The page containing the anchor was not shown. And a crash occured. the anchor was not shown. Desired behavior after PR is merged: The notebook shows the correct page and scrolls to the desired content. Tests have been written to maintain those behaviors. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79629
The maximum length for nameOnAccount is 22 characters [1]. Entering a longer name results in an unclear error message: Server Error We are not able to process your payment. E_WC_26: Please provide valid account holder name. A maxlength="22" on the input was considered as well, but it would be confusing for users and bank transactions with the first 22 characters should be accepted. opw-2688384 [1] https://developer.authorize.net/api/reference/features/acceptjs.html Forwar
Original PR description
The maximum length for nameOnAccount is 22 characters [1]. Entering a longer name results in an unclear error message: Server Error We are not able to process your payment. E_WC_26: Please provide valid account holder name. A maxlength="22" on the input was considered as well, but it would be confusing for users and bank transactions with the first 22 characters should be accepted. opw-2688384 [1] https://developer.authorize.net/api/reference/features/acceptjs.html Forward-Port-Of: odoo/odoo#79658
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78226
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78226
Seed is now fixed at beginning of each test to ensure random state is set once for all and avoid random issues. Task-2643740 Forward-Port-Of: odoo/odoo#79445 Forward-Port-Of: odoo/odoo#79432
Original PR description
Seed is now fixed at beginning of each test to ensure random state is set once for all and avoid random issues. Task-2643740 Forward-Port-Of: odoo/odoo#79445 Forward-Port-Of: odoo/odoo#79432
Fixes an issue where new followers would always be checked upon updating a task. Which could result in a lot more queries than necessary when changes are cascading. Use cache more in dependency tracking. TaskId-2693899 Forward-Port-Of: odoo/odoo#79931
Original PR description
Fixes an issue where new followers would always be checked upon updating a task. Which could result in a lot more queries than necessary when changes are cascading. Use cache more in dependency tracking. TaskId-2693899 Forward-Port-Of: odoo/odoo#79931
When trying to donate on the website without being logged in, having 'name' in your name would trigger a traceback. TaskId-2694024 Forward-Port-Of: odoo/odoo#79945
Original PR description
When trying to donate on the website without being logged in, having 'name' in your name would trigger a traceback. TaskId-2694024 Forward-Port-Of: odoo/odoo#79945
Currently, if we print the pricelist report after a refresh, the traceback will occur. It has been fixed. Task-ID: 2584806 Forward-Port-Of: odoo/odoo#79946 Forward-Port-Of: odoo/odoo#73225
Original PR description
Currently, if we print the pricelist report after a refresh, the traceback will occur. It has been fixed. Task-ID: 2584806 Forward-Port-Of: odoo/odoo#79946 Forward-Port-Of: odoo/odoo#73225
**[FIX] mail: consider more than last 1000 activities** Because `activities_to_check` was assigned in each loop, the result was only containing the last chunk of 1000 records, instead of the whole result. This commit fixes the issue by concatenating into the list instead of just assigning it. **[FIX] mail: fix performance issue on activities filter** Accessing `valid_docs.ids` for each activity to check was costly, and in my example the whole loop took 125 seconds to execute. By t
Original PR description
**[FIX] mail: consider more than last 1000 activities** Because `activities_to_check` was assigned in each loop, the result was only containing the last chunk of 1000 records, instead of the whole result. This commit fixes the issue by concatenating into the list instead of just assigning it. **[FIX] mail: fix performance issue on activities filter** Accessing `valid_docs.ids` for each activity to check was costly, and in my example the whole loop took 125 seconds to execute. By turning it into a set, the same loop takes 0.2 seconds to execute. When re-constructing the list based on ids to keep the order, using a set is also faster, and takes another 0.2 seconds instead of 13.6. Forward-Port-Of: odoo/odoo#79916
[FIX] point_of_sale: can't close session when negative split payment To reproduce: 1. Create Bank payment method with Identify Customer = True 2. Make order, use the bank payment method in 1. 3. Refund the order, again, use the bank payment method in 1. 4. Try to close the session. Error. This is because the account.payment object being creating has negative amount. We fix this issue in this commit by explicitly providing the destination account based on the partner, and reverting t
Original PR description
[FIX] point_of_sale: can't close session when negative split payment To reproduce: 1. Create Bank payment method with Identify Customer = True 2. Make order, use the bank payment method in 1. 3. Refund the order, again, use the bank payment method in 1. 4. Try to close the session. Error. This is because the account.payment object being creating has negative amount. We fix this issue in this commit by explicitly providing the destination account based on the partner, and reverting the destination and outstanding accounts when the payment amount is negative. TASK-ID: 2692252 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79861
Description of the issue/feature this PR addresses: - Create sale order with section and note - Go to Sale Analysis --> Issue : you see count of section and note  -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#75545
Original PR description
Description of the issue/feature this PR addresses: - Create sale order with section and note - Go to Sale Analysis --> Issue : you see count of section and note  -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#75545
When the user didn't allow the browser to use camera for scanning, pos shows unknown error message. Instead of unknown error, we show the error message raised by the scanBarcode method. TASK-ID: 2692252 Forward-Port-Of: odoo/enterprise#22282
Original PR description
When the user didn't allow the browser to use camera for scanning, pos shows unknown error message. Instead of unknown error, we show the error message raised by the scanBarcode method. TASK-ID: 2692252 Forward-Port-Of: odoo/enterprise#22282
When using the feature 'select related purchases' on the asset form, a user is able to select a journal item from another company. This should not be allowed, as the asset then uses an account from another company. Task-2684284 Forward-Port-Of: odoo/enterprise#22303 Forward-Port-Of: odoo/enterprise#22103
Original PR description
When using the feature 'select related purchases' on the asset form, a user is able to select a journal item from another company. This should not be allowed, as the asset then uses an account from another company. Task-2684284 Forward-Port-Of: odoo/enterprise#22303 Forward-Port-Of: odoo/enterprise#22103
latam 512 / adhoc 45551 --- In a customer instance, we found out that there is a problem with how are we managing the HINT for the events. We receive an Event code but we are printing this info as an Observation, and wrongly showing the observation name and hint message when this one is not needed, it is confusing and does not reflect the response. With this change, we are only showing the Event information and we are not adding any HINT: this one should only apply to errors and obser
Original PR description
latam 512 / adhoc 45551 --- In a customer instance, we found out that there is a problem with how are we managing the HINT for the events. We receive an Event code but we are printing this info as an…
latam 512 / adhoc 45551 --- In a customer instance, we found out that there is a problem with how are we managing the HINT for the events. We receive an Event code but we are printing this info as an Observation, and wrongly showing the observation name and hint message when this one is not needed, it is confusing and does not reflect the response. With this change, we are only showing the Event information and we are not adding any HINT: this one should only apply to errors and observation codes. Also, we fix the format of the AFIP Messages message that is added to the invoice chart, before is was show everything in one line because we were using the wrong break lines (`\n` instead of `<br/>`) Before  After  Forward-Port-Of: odoo/enterprise#22181 Forward-Port-Of: odoo/enterprise#22086
The cronjob that fetches DTE mails runs under OdooBot, which has superuser rights. This means that it ignores record rules and allowed company ids from the current context. `_get_partner` was looking for the contact of the issuer by searching purely on the VAT number. If there was a contact for the same VAT defined on a different company, that would otherwise be inaccessible to the company associated with the invoice, it would get matched as a result of that query and running as the super
Original PR description
The cronjob that fetches DTE mails runs under OdooBot, which has superuser rights. This means that it ignores record rules and allowed company ids from the current context. `_get_partner` was looking…
The cronjob that fetches DTE mails runs under OdooBot, which has superuser rights. This means that it ignores record rules and allowed company ids from the current context. `_get_partner` was looking for the contact of the issuer by searching purely on the VAT number. If there was a contact for the same VAT defined on a different company, that would otherwise be inaccessible to the company associated with the invoice, it would get matched as a result of that query and running as the superuser. This had several consequences. First the creation of the invoice would fail at the end of the `create()` function, throwing an exception: https://github.com/odoo/odoo/blob/cd144298c82dacd2e1919b79dd1c2307b55da64b/odoo/models.py#L3909 . Next that exception gets caught and a dummy record with no invoice lines is created: https://github.com/odoo/enterprise/blob/db280068a16c6f29a25de47c40e39ce02e1ec749/l10n_cl_edi/models/fetchmail_server.py#L253 . This leaves the user with two invoices. The first invoice will show a read access error when opening it, because the user won't be able to read the contact. The second invoice will be for the amount 0 and be empty. So there are two issues here: the query for the partner isn't specific enough, and if an exception happens when creating the invoice, the failed invoice persists. This commit makes `_get_partner` take into account the company id so the correct partner gets matched (or not if there is none). It will also match on contacts that don't have a company set and are thus available to all companies. It puts a savepoint context around the creation of the first invoice. If creating the invoice fails, it will be rolled back so no bad data gets left behind. opw-2633022 Forward-Port-Of: odoo/enterprise#21956
Steps to reproduce: - With multi-company and multi-currency enabled - Activate 'PEN' Currency - Activate 'Automatic Currency Rates' with 'Bank of Peru' as service - Set the interval as 'Daily' on next run on the current day - Select an other company and do the same - Go to Settings/Technical/Automation/Scheduled Actions and select 'Currency: rate update' - Click on 'Run Manually' Issue Got a traceback Raise ValueError 'Expect Singleton ...' opw-2683218 Forward-Port-Of: o
Original PR description
Steps to reproduce: - With multi-company and multi-currency enabled - Activate 'PEN' Currency - Activate 'Automatic Currency Rates' with 'Bank of Peru' as service - Set the interval as 'Daily' on next run on the current day - Select an other company and do the same - Go to Settings/Technical/Automation/Scheduled Actions and select 'Currency: rate update' - Click on 'Run Manually' Issue Got a traceback Raise ValueError 'Expect Singleton ...' opw-2683218 Forward-Port-Of: odoo/enterprise#22257
### Expected behavior Alert "_The scheduled action for alerts has been deleted. Update the Subscriptions module to re-create it._" shouldn't be displayed on every creation form. ### Current behavior On every creation form, there is an alert "_The scheduled action for alerts has been deleted. Update the Subscriptions module to re-create it._" displayed just under Alert Name. ### Steps to reproduce the error - Install Subscription app, - Go to Subscription -> Configuration -> Alerts
Original PR description
### Expected behavior Alert "_The scheduled action for alerts has been deleted. Update the Subscriptions module to re-create it._" shouldn't be displayed on every creation form. ### Current behavior On every creation form, there is an alert "_The scheduled action for alerts has been deleted. Update the Subscriptions module to re-create it._" displayed just under Alert Name. ### Steps to reproduce the error - Install Subscription app, - Go to Subscription -> Configuration -> Alerts - Create a new one ### Reason Display condition is based on computed field `cron_nextcall` for which the compute function hasn't been called yet. The function is only called when the creation form is saved or when opening an existing alert. OPW-2663057 Forward-Port-Of: odoo/enterprise#22200