Monday, September 13, 2021
17 changes · master
Enhancements to existing features
The barcode reception info view now only shows the Allocation button when there are items that can actually be allocated. It also saves current work before opening allocation-related screens, helping prevent users from losing changes during warehouse receiving workflows.
Original PR description
Small fix/improvement: 1. Make "Allocation" button show in "i" form view only when moves to allocate to. (i.e. match community behavior) 2. Commit changes when "i" button is clicked on. This is due to "Allocation" button opening a "new" window when opening the action. After OWL-ification, the default behavior when this occurs is to wipe any not committed changes. Obviously we do not want to lose our work when clicking on this button. Task: 2632884 COM PR: odoo/odoo#76147
The mail enterprise module updates its automated checks for attachments to match a newer interface component. This helps keep quality assurance aligned with the current product behavior without changing the user-facing attachment experience.
Original PR description
See https://github.com/odoo/odoo/pull/71722 Part of task-2365881
Resolved issues and error corrections
Repair order line subtotals now follow the company setting to show tax-included amounts. This prevents mismatches when taxes are added to repair lines and gives users totals that match their accounting display preference.
Original PR description
Steps to follow - Enable group_show_line_subtotals_tax_included - Create a repair order and add a tax to a line -> The subtotal doesn't contain the tax amount opw-2513287
Miscellaneous changes
Description of the issue/feature this PR addresses: Task: '2583718' Task: '2588145' -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76246
Original PR description
Description of the issue/feature this PR addresses: Task: '2583718' Task: '2588145' -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76246
A spelling mistake in a default mass mailing template was corrected from “expertize” to “expertise.” This improves the professionalism and clarity of template content shown to users and their recipients.
Original PR description
PURPOSE In mass_mailing default template there is typo of word expertize which should be improve to expertise SPECIFICATION Current: Currently in mass_mailing default template there is typo of word expertize. To BE: Change Expertize to Expertise Task Id: 2621328
Invoice extraction will no longer fail when an automatically extracted invoice is missing a required field during processing. This avoids unexpected errors and helps users continue reviewing or saving vendor bills created from extracted documents.
Original PR description
Disable the check of required fields in the Form emulator as the extraction system might leave it blank and cause a traceback on saving.
Before this commit. The move splitting was not considering _split return a list of values. This commit also add a bunche of missing tests Task : 2411102 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#76351
Original PR description
Before this commit. The move splitting was not considering _split return a list of values. This commit also add a bunche of missing tests Task : 2411102 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#76351
This commit fixes two bugs: 1) When the user changes the tracking of a product template with variants, they get a traceback. 2) When the user changes the tracking of a product with quantity available, the warning is not shown. For the 1), it was due to reading `tracking` and `qty_available` fields on a record set (happens when the template has variants). For the 2), it was due to the `qty_available` who is wrongly computed in the onchange because of the records having a "new-id" instea
Original PR description
This commit fixes two bugs: 1) When the user changes the tracking of a product template with variants, they get a traceback. 2) When the user changes the tracking of a product with quantity available, the warning is not shown. For the 1), it was due to reading `tracking` and `qty_available` fields on a record set (happens when the template has variants). For the 2), it was due to the `qty_available` who is wrongly computed in the onchange because of the records having a "new-id" instead of their usual id. How to reproduce: - Create a new product with some variants, no tracking; - Add quantities for those product variants; - Edit the product and change its tracking -> Traceback. task-2618203 Forward-Port-Of: odoo/odoo#75997
Issue: When resequencing an account_move, the chatter showed the resequencing but also a ghost change of state from draft to posted Steps to reproduce : 1) Create an invoice and post it 2) Look up the journal entry for the invoice and resequence it to some arbitrary other name 3) Check the chatter for that invoice, it shows a change from draft to posted Why is that a bug: The state isn't changed so it shouldn't be logged Side-Note: I don't understand why in the code until t
Original PR description
Issue: When resequencing an account_move, the chatter showed the resequencing but also a ghost change of state from draft to posted Steps to reproduce : 1) Create an invoice and post it 2) Look up the journal entry for the invoice and resequence it to some arbitrary other name 3) Check the chatter for that invoice, it shows a change from draft to posted Why is that a bug: The state isn't changed so it shouldn't be logged Side-Note: I don't understand why in the code until this commit we had to force change the state to draft to change the name of the move, when I tested, we can change the name of a posted move without any issue opw-2581248 Forward-Port-Of: odoo/odoo#75620
[FIX] website: add support for svg logo in configurator The configurator's palette selection screen didn't support SVG logo. On SVG upload primary and secondary colors couldn't be extracted and no palette was recommended. It comes from the fact that Python PIL library does not support SVG. We therefore had to convert SVG to PNG before trying to extract primary and secondary colors. The function allowing to convert a SVG to a PNG has been added as an utility function in website.utils
Original PR description
[FIX] website: add support for svg logo in configurator The configurator's palette selection screen didn't support SVG logo. On SVG upload primary and secondary colors couldn't be extracted and no…
[FIX] website: add support for svg logo in configurator The configurator's palette selection screen didn't support SVG logo. On SVG upload primary and secondary colors couldn't be extracted and no palette was recommended. It comes from the fact that Python PIL library does not support SVG. We therefore had to convert SVG to PNG before trying to extract primary and secondary colors. The function allowing to convert a SVG to a PNG has been added as an utility function in website.utils and is used for the upload of document in website_slides. This function add support for a specific case which was not supported by the previous conversion function used for the document upload in website_slides: SVG without width and height attributes on Firefox. task-2602521 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#74956
Before this commit several history steps were added when picking a color and history steps were added when previewing a color. After this commit history is only updated on color selection and not during color preview: applying the color relies on execCommand which adds an history step => no need to add another step upon picking a color but must be prevented during preview. task-2599771 Description of the issue/feature this PR addresses: Current behavior before PR: Desired beha
Original PR description
Before this commit several history steps were added when picking a color and history steps were added when previewing a color. After this commit history is only updated on color selection and not during color preview: applying the color relies on execCommand which adds an history step => no need to add another step upon picking a color but must be prevented during preview. task-2599771 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#76208
Before this commit, there could be tracebacks after changing the srcObject of the audioElement of the rtcSession, this commit fixes this issue by calling `load` on the element after changing the srcObject. Forward-Port-Of: odoo/odoo#76344
Original PR description
Before this commit, there could be tracebacks after changing the srcObject of the audioElement of the rtcSession, this commit fixes this issue by calling `load` on the element after changing the srcObject. Forward-Port-Of: odoo/odoo#76344
Before this commit, we would attempt to notify peers that we are disconnecting when resetting mailRtc, which was not necessary as peers already close the peer connection when the server notifies them that the call participation changed. Forward-Port-Of: odoo/odoo#76347
Original PR description
Before this commit, we would attempt to notify peers that we are disconnecting when resetting mailRtc, which was not necessary as peers already close the peer connection when the server notifies them that the call participation changed. Forward-Port-Of: odoo/odoo#76347
Steps to reproduce (using documents app): 1. Create a new document request 2. Select the created document request, enable the chatter 3. Upload a document using the document request icon 4. Hide the chatter 5. Show the chatter Odoo Client Error OPW-2643331 Forward-Port-Of: odoo/odoo#76364
Original PR description
Steps to reproduce (using documents app): 1. Create a new document request 2. Select the created document request, enable the chatter 3. Upload a document using the document request icon 4. Hide the chatter 5. Show the chatter Odoo Client Error OPW-2643331 Forward-Port-Of: odoo/odoo#76364
[FIX] l10n_eu_oss_reports: XML export is only available for BE, LU Since all EU countries XML export's are not yet available, the XML button is hidden [IMP] l10n_eu_oss_reports: restrict XML export date ranges Only monthly and quarterly date ranges are supported in the XML exports for both BE and LU. An error message is displayed if this condition is not met Forward-Port-Of: odoo/enterprise#20753
Original PR description
[FIX] l10n_eu_oss_reports: XML export is only available for BE, LU Since all EU countries XML export's are not yet available, the XML button is hidden [IMP] l10n_eu_oss_reports: restrict XML export date ranges Only monthly and quarterly date ranges are supported in the XML exports for both BE and LU. An error message is displayed if this condition is not met Forward-Port-Of: odoo/enterprise#20753
**Current behaviour** *GIVEN* an invoice with document type 33 *AND* a line with withholding tax *WHEN* confirm the invoice *THEN* the invoice is not posted due to -> Receipts with withholding taxes are not allowed **Expected behaviour** The invoice is posted Forward-Port-Of: odoo/enterprise#20072
Original PR description
**Current behaviour** *GIVEN* an invoice with document type 33 *AND* a line with withholding tax *WHEN* confirm the invoice *THEN* the invoice is not posted due to -> Receipts with withholding taxes are not allowed **Expected behaviour** The invoice is posted Forward-Port-Of: odoo/enterprise#20072
When a user submit an expense and try to send it to invoice_ocr service, we have to create the account first if this is the first call. It will allow elligible database to get free credits too Forward-Port-Of: odoo/enterprise#20732
Original PR description
When a user submit an expense and try to send it to invoice_ocr service, we have to create the account first if this is the first call. It will allow elligible database to get free credits too Forward-Port-Of: odoo/enterprise#20732