Wednesday, December 22, 2021
26 changes · master
Enhancements to existing features
Calendar event organizers are now informed when some attendees have missing or invalid email addresses. This helps them understand that those attendees will not receive email notifications and can correct the contact details if needed.
Original PR description
If some attendees of an event have an empty or invalid email address, the organizer of this event should be informed that these attendees won't receive any email notifications. opw-2667016 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Batch payments now include a communication area where users can track changes, add notes, schedule tasks, and receive activity notifications. This makes payment follow-up easier and improves visibility for teams managing batch payment workflows.
Original PR description
Currently: batch payments don't have a chatter and the changes cannot be tracked. Desired: users want to be to able track changes, make notes, and schedule tasks. Task ID: 2711574 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds a new way for users to open and view the current website directly inside the Website app dashboard. It helps teams preview or access the live website more quickly without leaving the Odoo back office.
Original PR description
[WIP] task-2687506
Manufacturing backorders are now processed more efficiently when work orders are involved. This should reduce delays for users managing larger or more complex production runs, while keeping the functional behavior largely unchanged.
Original PR description
Rename generate_backorder_productions_multi to split_production Make generate_backorder_productions take advantage of split_production task 2633369
Resolved issues and error corrections
New records no longer show the text “False” as their display name or breadcrumb when a form includes the display name field. This prevents confusing placeholder text and keeps the create flow showing the expected “New” label.
Original PR description
If a form view contains the field `display_name`, when creating a new record, the initial value of `display_name` is the string `"False"`, and that weird value also appears in the breadcrumb instead of `"New"`. In order to avoid this unexpected behavior, the conversion of a value to a display name should be `False`, like any other field would.
Code cleanup and technical improvements
This update reorganizes how file uploads are handled in the Mail app, including activities, attachment boxes, and message composers. It should make upload behavior easier to maintain and support more consistent attachment handling for users.
Miscellaneous changes
Consider this example: - Create a 42% tax, price-included, with two tax repartition lines doing +100 -100 - Create an invoice of 100€ using this tax, and look at the move lines generated ==> Only a base line of 100 and a receivable/payable line of 100 have been created; no tax line. This is wrong, as we'd expect to see: - 100 in payable/receivable - 100 for the base line - 42 for the +100 tax repartition line - -42 for the -100 tax repartition line The two tax lines are missin
Original PR description
Consider this example: - Create a 42% tax, price-included, with two tax repartition lines doing +100 -100 - Create an invoice of 100€ using this tax, and look at the move lines generated ==> Only a base line of 100 and a receivable/payable line of 100 have been created; no tax line. This is wrong, as we'd expect to see: - 100 in payable/receivable - 100 for the base line - 42 for the +100 tax repartition line - -42 for the -100 tax repartition line The two tax lines are missing because the compute_all considers the tax as a 0% one, because of the +100 -100 stuff. OPW 2716083 Forward-Port-Of: odoo/odoo#81733 Forward-Port-Of: odoo/odoo#81725
Manufacturing orders with multiple serial numbers are now split in batches instead of one by one, greatly reducing processing time for large production runs. The change also adds a warning when mass producing with components from multiple lots, helping users confirm the action is intentional.
Original PR description
There is 2 major issues with the production of multiple serials number - Performance issue - Duplicated code with classic backorder mechanism The performance issues exist since backorders were create…
There is 2 major issues with the production of multiple serials number - Performance issue - Duplicated code with classic backorder mechanism The performance issues exist since backorders were create one by one and `stock.move` and `stock.move.line` are always recomputed. They are not created in batch neither. _generate_backorders is removed and replace by _split_productions. The functionality are the same. Technicaly it does the maximum in batch, first it creates all the `mrp.production` then all the `stock.move` and finaly, it splits the existing `stock.move.line` among the new `stock.move` It means that the reservation is not recompute anymore during a backorder process and will remain the same than the splitted production order. Performance metrics (10 components): | # | 2 | 10 | 100 | 1000 | |----------|------------|----------|----------|-------------| | Before | 0.47s | 2.84s | 32.25s | 580.53s | | After | 0.13s | 0.36s | 2.60s | 35.17s | task 2633369
Added a CoA that provides accounts needed for legal reports Added taxes (sales taxes and service sales tax, even provincial) Reports are in enterprise Task : https://www.odoo.com/mail/view?model=project.task&res_id=2695796&access_token=55e71bd4-850c-4fb4-a030-56bb333f59b4 Description of the issue/feature this PR addresses: Pakistan localization for accounting Current behavior before PR: No specific accounts or reports for Pakistan Desired behavior after PR is merged: COA, BS, P&L
Original PR description
Added a CoA that provides accounts needed for legal reports Added taxes (sales taxes and service sales tax, even provincial) Reports are in enterprise Task : https://www.odoo.com/mail/view?model=project.task&res_id=2695796&access_token=55e71bd4-850c-4fb4-a030-56bb333f59b4 Description of the issue/feature this PR addresses: Pakistan localization for accounting Current behavior before PR: No specific accounts or reports for Pakistan Desired behavior after PR is merged: COA, BS, P&L and taxes available for Pakistan -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#80633
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81629
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#81629
The PR #75475 removed the method `_compute_manager_id` without removing the reference in the field. 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#81752
Original PR description
The PR #75475 removed the method `_compute_manager_id` without removing the reference in the field. 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#81752
A bug[0] was detected in the Odoo Docker image 15.0 when trying to print invoices with arabic fonts (and probably other languages that need specific font) . It appears that the necessary fonts are not available in the container image. Strangely, the issue did not exists in previous Odoo Docker images. It appears that `fonts-dejavu-core` package was installed incidentally by `wkhtmltox`[1] which is installed from the official website. Note that the Debian version of `wkhtmltopdf`[2] do
Original PR description
A bug[0] was detected in the Odoo Docker image 15.0 when trying to print invoices with arabic fonts (and probably other languages that need specific font) . It appears that the necessary fonts are…
A bug[0] was detected in the Odoo Docker image 15.0 when trying to print invoices with arabic fonts (and probably other languages that need specific font) . It appears that the necessary fonts are not available in the container image. Strangely, the issue did not exists in previous Odoo Docker images. It appears that `fonts-dejavu-core` package was installed incidentally by `wkhtmltox`[1] which is installed from the official website. Note that the Debian version of `wkhtmltopdf`[2] does not provide this dependency. In the 15.0 Docker image, while the `wkhtmltox` is installed the same way, the `fonts-dejavu-core` package was not installed because the dependency of `fontconfig-config`[3] was already fulfilled by the `python3-renderpm`[4] from Debian Bullseye. Finally, to add more confusion, the Odoo package have an indirect dependency on `fonts-dejavu-core` through the `python3-pydot`[5] package. This explains why the issue was not found before. In order to avoid all this spaghetti dependency hell, this commit adds an explicit dependency on one of the multilingual fonts available in the Debian packages. [0] https://github.com/odoo/docker/issues/400 [1] https://github.com/wkhtmltopdf/wkhtmltopdf/releases/0.12.5/ [2] https://packages.debian.org/bullseye/wkhtmltopdf [3] https://packages.debian.org/bullseye/fontconfig-config [4] https://packages.debian.org/bullseye/python3-renderpm [5] https://packages.debian.org/bullseye/python3-pydot Forward-Port-Of: odoo/odoo#81689
Scale up game has been printed with the quantity show by default on the supplier info. So we copy that behavior in standard for educational purpose and avoid to print again all the scale up. Also it's better from a usablity point of view since it's an important information. opw-fp Forward-Port-Of: odoo/odoo#81750
Original PR description
Scale up game has been printed with the quantity show by default on the supplier info. So we copy that behavior in standard for educational purpose and avoid to print again all the scale up. Also it's better from a usablity point of view since it's an important information. opw-fp Forward-Port-Of: odoo/odoo#81750
When clicking on save, the saved HTML should be what the user currently sees. Before this commit, there might be cases where clicking on save actually triggers a DOM update which occurs too late for the change to be considered for the save. In 15.0, this manifests for example with the blog cover saving*: if the color is being changed with the colorpicker and that the user does not close the colorpicker before saving, the color change is not considered because the previewMode=false update
Original PR description
When clicking on save, the saved HTML should be what the user currently sees. Before this commit, there might be cases where clicking on save actually triggers a DOM update which occurs too late for the change to be considered for the save. In 15.0, this manifests for example with the blog cover saving*: if the color is being changed with the colorpicker and that the user does not close the colorpicker before saving, the color change is not considered because the previewMode=false update of the colorpicker is not received. With this commit, we ensure that DOM updates which occur because of the click on the save button are considered before saving. * That bug is however due to two other issues which are being fixed with the PR at [1]. [1]: https://github.com/odoo/odoo/pull/79028 Forward-Port-Of: odoo/odoo#81732
Before this PR, user could edit notifications message. task-2713602 Forward-Port-Of: odoo/odoo#81753 Forward-Port-Of: odoo/odoo#81650
Original PR description
Before this PR, user could edit notifications message. task-2713602 Forward-Port-Of: odoo/odoo#81753 Forward-Port-Of: odoo/odoo#81650
Issues ------ In the module sale, with the automatic invoicing configured. Payment transaction generate, post and send the invoice when they are post process. In some country the invoice is not directly ready to be sent due to some edi document Solution -------- use the mechanism introduce with https://github.com/odoo/odoo/commit/3a29371eb70309f46e3b8938434287fefc23b351 to delay the sending. Introduce a cron that check invoice to send -- I confirm I have signed the CLA
Original PR description
Issues ------ In the module sale, with the automatic invoicing configured. Payment transaction generate, post and send the invoice when they are post process. In some country the invoice is not directly ready to be sent due to some edi document Solution -------- use the mechanism introduce with https://github.com/odoo/odoo/commit/3a29371eb70309f46e3b8938434287fefc23b351 to delay the sending. Introduce a cron that check invoice to send -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81252 Forward-Port-Of: odoo/odoo#80915
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81772 Forward-Port-Of: odoo/odoo#81265
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#81772 Forward-Port-Of: odoo/odoo#81265
Before this commit, the ripple effect did not work when a button was not in the same location/size when clicked compared to its position/size when the page was loaded. (e.g. after scrolling the page) task-2686370 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#80611
Original PR description
Before this commit, the ripple effect did not work when a button was not in the same location/size when clicked compared to its position/size when the page was loaded. (e.g. after scrolling the page) task-2686370 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#80611
When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain. For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from: `"John D" <john@doe.com>` it will rewrite it to: `"John D (john@doe.com)" <notifications@example.com>` This will make sure the system never sends o
Original PR description
When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to…
When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain.
For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from:
`"John D" <john@doe.com>`
it will rewrite it to:
`"John D (john@doe.com)" <notifications@example.com>`
This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.)
During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender.
Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would).
As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course).
This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none.
So after the patch, the rewritten address is now:
`"John D" <notifications@example.com>`
When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages.
Forward-Port-Of: odoo/odoo#81473
Forward-Port-Of: odoo/odoo#79979Current behavior : When using cash rounding method "HALF-UP" if the difference between the rounded price and the original price was exactly half of the cash rounding, the order would appear as unpaid. Steps to reproduce : - Create a rounding method of 0.5 (half-up) - Sell a product for 11.25 - The order appears unpaid in the PoS orders list view opw-2593687 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81747 Forw
Original PR description
Current behavior : When using cash rounding method "HALF-UP" if the difference between the rounded price and the original price was exactly half of the cash rounding, the order would appear as unpaid. Steps to reproduce : - Create a rounding method of 0.5 (half-up) - Sell a product for 11.25 - The order appears unpaid in the PoS orders list view opw-2593687 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81747 Forward-Port-Of: odoo/odoo#81642
When adding a new product, if the user then clicks on "Replenish", the product disappears To reproduce the issue: (Use demo data) 1. In MPS, add a product: [FURN_78236] Table Kit 2. Click on "Replenish" for this specific product Error: The line disappears. When loading again the MPS page, the line is back and clicking again on "Replenish" won't reproduce the issue Once the replenishment is done, the page is reloaded: https://github.com/odoo/enterprise/blob/b7168a46901aacbb4957fa17
Original PR description
When adding a new product, if the user then clicks on "Replenish", the product disappears To reproduce the issue: (Use demo data) 1. In MPS, add a product: [FURN_78236] Table Kit 2. Click on "Replenish" for this specific product Error: The line disappears. When loading again the MPS page, the line is back and clicking again on "Replenish" won't reproduce the issue Once the replenishment is done, the page is reloaded: https://github.com/odoo/enterprise/blob/b7168a46901aacbb4957fa17cc44a70ba2ce1cf6/mrp_mps/static/src/js/client_action.js#L185-L192 and this will lead to https://github.com/odoo/enterprise/blob/b7168a46901aacbb4957fa17cc44a70ba2ce1cf6/mrp_mps/static/src/js/client_action.js#L284-L291 But here is the issue: when adding the product (step 01), nothing adds the new line in `active_ids`. This is the reason why this line "disappears" OPW-2662244 Forward-Port-Of: odoo/enterprise#23003
Side effect of commit https://github.com/odoo/enterprise/commit/7a3fb9fb185e09d7caab8f99d74de152d0003ae6 Before this commit, we were retrieving start and end balances according to the following preference order : - OPBD, PRCD, OPAV, ITBD for start balance - CLBD, CLAV, ITBD for end balance After this commit, we are now wrongly retrieving these balances in the order of the camt file for both start and end balances. We should keep the existing behavior no matter which order is defined
Original PR description
Side effect of commit https://github.com/odoo/enterprise/commit/7a3fb9fb185e09d7caab8f99d74de152d0003ae6 Before this commit, we were retrieving start and end balances according to the following preference order : - OPBD, PRCD, OPAV, ITBD for start balance - CLBD, CLAV, ITBD for end balance After this commit, we are now wrongly retrieving these balances in the order of the camt file for both start and end balances. We should keep the existing behavior no matter which order is defined in the camt file. opw-2696445 Forward-Port-Of: odoo/enterprise#22750
Filters were not the right color (gray instead of green) and were not inline with journal filters. Convert from <a> to <button> same as other account_report filter buttons. Task: 2715144 Forward-Port-Of: odoo/enterprise#22931
Original PR description
Filters were not the right color (gray instead of green) and were not inline with journal filters. Convert from <a> to <button> same as other account_report filter buttons. Task: 2715144 Forward-Port-Of: odoo/enterprise#22931
The report forms compute the sums using as a domain the codes of the groups of the Chart of Accounts, using a standard one created for the Pakistan. Linked to odoo pull request #80633 Task : https://www.odoo.com/mail/view?model=project.task&res_id=2695796&access_token=55e71bd4-850c-4fb4-a030-56bb333f59b4 Forward-Port-Of: odoo/enterprise#22618
Original PR description
The report forms compute the sums using as a domain the codes of the groups of the Chart of Accounts, using a standard one created for the Pakistan. Linked to odoo pull request #80633 Task : https://www.odoo.com/mail/view?model=project.task&res_id=2695796&access_token=55e71bd4-850c-4fb4-a030-56bb333f59b4 Forward-Port-Of: odoo/enterprise#22618
Followup messages can contain variables. The "%(amount_due)s" variable is replaced with the "partner.total_due" value. Before this fix, partner.total_due was the sum of all unpaid invoices, blocked or not. This led to an inconsistency between the "Total Due" amount in the followup report (that would not include blocked invoices) and the amount in the followup message (including blocked invoices). With this fix, blocked invoices are not added to "partner.total_due" anymore. The followup report
Original PR description
Followup messages can contain variables. The "%(amount_due)s" variable is replaced with the "partner.total_due" value. Before this fix, partner.total_due was the sum of all unpaid invoices, blocked or not. This led to an inconsistency between the "Total Due" amount in the followup report (that would not include blocked invoices) and the amount in the followup message (including blocked invoices). With this fix, blocked invoices are not added to "partner.total_due" anymore. The followup report view is also updated now when total_due value changes. Task: 2684627 Forward-Port-Of: odoo/enterprise#23022 Forward-Port-Of: odoo/enterprise#22464
If the rut of the company is shorter than 8 characters, without counting the verification digit, we get a ValueError After this PR: the strip for the number is being executed starting from the reverse (from right to left instead of left to right) Forward-Port-Of: odoo/enterprise#22786 Forward-Port-Of: odoo/enterprise#22748
Original PR description
If the rut of the company is shorter than 8 characters, without counting the verification digit, we get a ValueError After this PR: the strip for the number is being executed starting from the reverse (from right to left instead of left to right) Forward-Port-Of: odoo/enterprise#22786 Forward-Port-Of: odoo/enterprise#22748