Daily updates from Odoo
Navigate
Branch
Thursday, January 30, 2020
43 changes
New functionality added to Odoo
Event organizers can now create and manage multiple ticket types directly in the Events app, without installing Sales or eCommerce. This helps teams that collect payments offline, such as by bank transfer, while still using Odoo for ticketing, registrations, attendee details, and event website signups.
Original PR description
PURPOSE Integration between event and eCommerce is required only when users handle the entire selling process online. However users may require ticketing support while managing payments outside of…
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
See sub commits for more details. Here are a sample of main specifications
linked to this task.
SPECIFICATIONS: TICKET MOVE / SPLIT
Remove the need to have event_sale installed to manage basic ticketing on
events.
Move ticket model (event.event.ticket) directly into event, copying most
fields from event_sale. Only sale specific fields and behavior should be kept
in event_sale :
* keep product_id and price information in event_sale;
* keep sales analysis in event_sale;
We also split tickets model used for event type (event.type.ticket) and
events (event.event.ticket). Indeed previously to this commit both are
modeled in the same table, with the following issues :
* tickets on templates use only a subset of fields: name, seats availability,
product, price;
* a ticket has either an event_id, either an event_type_id, and there are
constraints to try to avoid having lost tickets. This leads to a strange
model where m2o fields are required only in some cases with a dual
behavior;
* tickets are not shared between event.type and event.event. They are copied
and having a single model is therefore not necessary;
We therefore choose to have a light model for event.type.ticket. It is linked
to event.type when configuring template tickets. They are copied in the
onchange copying event template configuration to the event itself, leading
to event.event.ticket creation.
Some tests are moved / completed accordingly.
Access rights are copied from website_event_sale to website_even concerning
ticket access for public / portal. Currently they are kept as they are with
some rewording as it is not the purpose of this commit to rewrite them.
SPECIFICATIONS: FRONTEND
In this commit we move frontend part of ticket support from website_event_sale
to website_event. Now eCommerce / event integration adds only payment
information when registering.
About tickets
* if there is no ticket -> generic registration allowed;
* if there is one ticket -> quick registration box;
* more than one ticket -> unfolding registration box with all available
tickets;
About price
* sale not installed -> no mention of price. A ticket without price is not
free. Its description allow to tell how to pay for example;
* a price is set: price is displayed;
* no price is set: FREE is displayed;
Most event frontend templates and controllers are therefore moved from
website_event_sale to website_event. Only part about pricing and sale order
creation is now located in website_event_sale.
Buy flow remains mainly untouched. Indeed this commit is mainly about moving
template to support tickets.
SPECIFICATIONS: improve ticket model and fields propagation
Remove date fields from event.type.ticket
Propagate seats definition from ticket template to tickets
Add a description on tickets to use in frontend
Improve naming of event tickets
LINKS
Task ID 2177281
Community PR #43488Adds a new website building block that creates a sticky table of contents linked to page headings, helping visitors navigate longer pages more easily. It also improves anchor scrolling so linked sections appear correctly below fixed menus and refines editor drop-zone behavior when placing content blocks.
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
Employees can now upload a receipt photo and have key expense details such as description, date, reference, and total filled in automatically using an extraction service. The system can also suggest the right expense product based on previous expense descriptions, reducing manual entry and improving consistency.
Original PR description
first implementation of the expense extract module --------------------------------------------------------------------- use the iap-extract service to fill the description/date/bill reference and total of the expense base on the receip picture.
Enhancements to existing features
Businesses can now set a cutoff date so older invoices and payments from the Invoicing app are ignored when moving to full Accounting. This makes migration simpler by letting teams cancel legacy records and reimport opening balances without duplicating accounting impact.
Original PR description
This is done by introducing a new threshold setting, allowing choosing a date before which all invoices and payments have to be ignored by the accounting. Once this is done, all the balances can be reimported directly, easing the migration to Odoo Accounting a lot. account.move objects having to be ignored because of this are cancelled, and receive the new 'from_invoicing' payment state. account.payment objects are moved to the new 'from_invoicing' state and their related account.move is cancelled and marked as from invoicing as well. Task: 2092377
Manufacturing users can now adjust component quantities and add new components to confirmed manufacturing orders when the bill of materials allows flexible consumption. The update also lets teams choose the work order where new components are consumed and improves availability and lot-tracking checks for more reliable production handling.
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
Ribbon labels in the web interface now better handle longer text by adjusting the display and allowing multiple lines. This makes status or context labels easier to read, and optional tooltips can provide extra explanation without cluttering the screen.
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
List view sidebar actions now receive a clear indicator when users selected all records using the header checkbox instead of choosing individual records. This helps business actions, especially accounting workflows, correctly understand whether they should apply to a full filtered set or only selected visible records.
Original PR description
In a list view, select some records (either by selecting them one by one, or by clicking on the header to select all records), then click on an action (except for the special case of 'Export) in the…
In a list view, select some records (either by selecting them one by one, or by clicking on the header to select all records), then click on an action (except for the special case of 'Export) in the sidebar. Some information about the selection is put into the context: - active_ids: the ids of the selected records (only those of the current page) - active_domain: the current domain However, before this commit, there were no way to determine whether the user checked the header checkbox (i.e. all records), or some of them individually. This commit adds the information, with a 'select_all' key in the context. Note that this is a quick solution, as we need it right now for an accounting usecase. A more elaborate solution, which will allow the user to choose whether he wants to apply the action on the selected ids or on the whole domain, will be developped soon. Part of Task 2146469 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 accounting general ledger now includes a default cumulative balance view, making it easier to follow how account balances evolve line by line. Users can also use a simple balance field for grouping and selected-line totals, while journal views keep it hidden by default to avoid clutter.
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 Point of Sale customer list now shows only customers linked to the company currently being used. This helps staff choose the right customer records and reduces confusion in multi-company environments.
Original PR description
**Task**: https://www.odoo.com/web#id=2145607&model=project.task&menu_id=4720 **Pad**: https://pad.odoo.com/p/r.7168a8e8210fa7cc810cdf56eb92dc19 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Avatar images shown on kanban cards now appear round instead of square. This provides a cleaner, more consistent visual presentation for users browsing records in kanban views.
Original PR description
Change the style of avatar images in kanban cards to make them round. Task 2179548
Companies can now set a cutoff date so older invoices and payments from the Invoicing app are ignored during accounting setup. This helps teams migrate to Odoo Accounting more smoothly by allowing balances to be reimported without old transactions disrupting the books.
Original PR description
This is done by introducing a new threshold setting, allowing choosing a date before which all invoices and payments have to be ignored by the accounting. Once this is done, all the balances can be reimported directly, easing the migration to Odoo Accounting a lot. account.move objects having to be ignored because of this are cancelled, and receive the new 'from_invoicing' payment state. account.payment objects are moved to the new 'from_invoicing' state and their related account.move is cancelled and marked as from invoicing as well. Task: 2092377
Manufacturing users can now add extra components directly to a specific work order when the bill of materials allows flexible consumption. The update also helps ensure products tracked by lot or serial number keep the required link between consumed and finished lots, improving traceability.
Original PR description
Consuming product tracked by lot (or serial number ) to produce product also tracked must ensure the link between the two lots (consumed and produced) is always set. This test is not done in community version while there is one in the enterprise conterpart (mrp_workorder module). This commit move this test to the mrp module to have it everywhere
Quality rules can now cover multiple products and operations, reducing duplicate setup for teams managing inspections. The update also improves quality check visibility, supplier traceability, team-specific stages, and issue notes so managers can track quality outcomes more effectively.
Users can now delete default IP ranges from the IoT scanning list when they know their IoT Box is not there. This helps reduce unnecessary scanning time and lowers network load during device discovery.
Original PR description
A few weeks ago, we've added default IP ranges to scan. When you know that the IoT Box is not in those ranges, you might want to delete the range from the list in order to save some time and load on the network. TaskID: 2151455
Resolved issues and error corrections
This fix makes web templates easier and more consistent to inherit when their names include a module prefix. It reduces configuration mistakes for developers and helps prevent template-related issues in the web interface, with a related fix avoiding a naming conflict in the upload progress display.
Original PR description
A good practice is to always prefix the name of a template by the name of the module it is defined in. So in the case where a template ```xml <t t-name="module.template" /> ``` was inherited by another Before this commit, one should have written ```xml <t t-name="other" t-inherit="module.module.template" /> ``` After this commit, it becomes more natural, and one should only write ```xml <t t-name="other" t-inherit="module.template"/>
Fixed an error that could prevent users from unbuilding a manufacturing order. This helps manufacturing teams complete reverse production actions without encountering a system traceback.
Original PR description
We get a traceback when we try to unbuild a MO due to a inexistant field call (scrap_qty) instead of product_qty -> 8458cc18674b267e64f95aa311a210ed5be41c51. Fix the issue.
Turning off pricelists in Point of Sale settings now also disables pricelist use in all POS configurations. This prevents pricelists from still appearing or being usable at checkout after the business option has been deactivated.
Original PR description
This commit prevent the use of the pricelist in the pos after deactivating the option in the res config setting. Before, the xml was not shown anymore but the option use_pricelist was still True and we could still see the pricelist in the frontend of the POS. We were unable to change the option in the backend. Now, when we untick the option in the res config setting, we disable all 'use_pricelist' in the pos configs. task-id: 2151669 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Documents app now respects the intended delay before opening the inspector on mobile. This prevents the inspector from appearing too quickly and keeps the mobile browsing experience consistent with recent interface changes.
Original PR description
Following the change of the inspector rendering in #7911, the mobile inspector wasn't taking the delay into account. This commit fixes this issue.
Fixes a template formatting issue that could cause Website CRM scoring pages to fail when loading. This helps keep affected sales and marketing views accessible after a recent translation-related change.
Original PR description
Task : https://www.odoo.com/web#id=2182586&action=333&active_id=965&model=project.task&view_type=form&menu_id=4720
This update removes an outdated validation in asset accounting after a field change, preventing unnecessary checks from running. It also corrects how asset-related balances are read so calculations use the right filtering and ordering, reducing the risk of incorrect asset accounting behavior.
Original PR description
The field asset_id has been changed to asset_ids in 66c53e43eddc6a6e0511c9f5700f3d5ab191a7d9 The check done in _check_original_move_line_ids is no longer needed. Also, the resolve_2many_commands we trying to access cumulated_balance without the order and domain set in the domain, which was problematic.
Code cleanup and technical improvements
This update refines an internal test for Gantt view access rights by avoiding duplicate demo user setup. It helps keep the test suite simpler and more reliable without changing business features or user workflows.
Original PR description
rev[0] introduced a test on the auto acl on gantt view and used the TransactionCaseWithUserDemo class. With this class, there's already a demo user present. [0] 3839e122d9e2ebf1faa848b01e1631e6c6f7d809
Miscellaneous changes
The access right on payment_token is based on the partner_id linked with the user If there is token link with the public user, they are shown for every request were the partner_id is not defined If you are logged with an internal user with sales access right, you'll see all the payment_token linked with the acquirer We should avoid both situation and show only the payment_token from the legit partner_id the one of the current user or the one given as parameter -- I confirm I have
Original PR description
The access right on payment_token is based on the partner_id linked with the user If there is token link with the public user, they are shown for every request were the partner_id is not defined If you are logged with an internal user with sales access right, you'll see all the payment_token linked with the acquirer We should avoid both situation and show only the payment_token from the legit partner_id the one of the current user or the one given as parameter -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44319
Before this commit, when clicking on a channel mention from a chat window, it crashed with the following error: `TypeError: channel.detach is not a function` This happens due to `MailService.joinChannel()` returning a promise that is resolved with channel ID, instead of a channel object. `channel.detach()` becomes `<Number>.detach()`, which is treated like `undefined()`, hence crash. Forward-Port-Of: odoo/odoo#44293 Forward-Port-Of: odoo/odoo#44228
Original PR description
Before this commit, when clicking on a channel mention from a chat window, it crashed with the following error: `TypeError: channel.detach is not a function` This happens due to `MailService.joinChannel()` returning a promise that is resolved with channel ID, instead of a channel object. `channel.detach()` becomes `<Number>.detach()`, which is treated like `undefined()`, hence crash. Forward-Port-Of: odoo/odoo#44293 Forward-Port-Of: odoo/odoo#44228
…s value. Description of the issue/feature this PR addresses: Current behavior before PR: It was raising the singleton error when updating multiple category records. Desired behavior after PR is merged: It will fix the singleton error. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44244
Original PR description
…s value. Description of the issue/feature this PR addresses: Current behavior before PR: It was raising the singleton error when updating multiple category records. Desired behavior after PR is merged: It will fix the singleton error. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44244
Before this commit, when typing something in the search view in Japanese, and then clicking on a suggestion from the IME dropdown menu, the search view menu did not update with selection. Steps to reproduce: - Enable Japanese IME in hiragana mode; - Type "test" in search view; - Soft-select another suggestion item, e.g. "テスト"; - Double-click on suggestion item "test"; => The search view menu still detects "テスト". As a result, clicking on any of these search view suggested filters
Original PR description
Before this commit, when typing something in the search view in Japanese, and then clicking on a suggestion from the IME dropdown menu, the search view menu did not update with selection. Steps to reproduce: - Enable Japanese IME in hiragana mode; - Type "test" in search view; - Soft-select another suggestion item, e.g. "テスト"; - Double-click on suggestion item "test"; => The search view menu still detects "テスト". As a result, clicking on any of these search view suggested filters picks "テスト" instead of "test". This commit fixes the issue by updating search menu when clicking in a suggestion in the IME menu. opw-2061590 Forward-Port-Of: odoo/odoo#44224 Forward-Port-Of: odoo/odoo#43723
Description of the issue/feature this PR addresses: The pagination of the events list is incorrectly aligned with the layout. Plus, if you deactivate the sidebar, the pager is inlined with the events. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42195
Original PR description
Description of the issue/feature this PR addresses: The pagination of the events list is incorrectly aligned with the layout. Plus, if you deactivate the sidebar, the pager is inlined with the events. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42195
-github issue: 14673 -task: 2007300 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44288 Forward-Port-Of: odoo/odoo#40847
Original PR description
-github issue: 14673 -task: 2007300 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44288 Forward-Port-Of: odoo/odoo#40847
The issue is: the user wants to send an invoice to a customer, changes the email template, and after the onchange, the field "Template" of the wizard is empty. Here is what happens. The onchange on the template renders a PDF file with the corresponding invoice document. The rendering builds some assets to convert the invoice to a PDF document, and former assets are deleted. The deletion of former assets (`ir.attachment` records) invalidates the whole record cache, which implicitly cl
Original PR description
The issue is: the user wants to send an invoice to a customer, changes the email template, and after the onchange, the field "Template" of the wizard is empty. Here is what happens. The onchange on…
The issue is: the user wants to send an invoice to a customer, changes the email template, and after the onchange, the field "Template" of the wizard is empty. Here is what happens. The onchange on the template renders a PDF file with the corresponding invoice document. The rendering builds some assets to convert the invoice to a PDF document, and former assets are deleted. The deletion of former assets (`ir.attachment` records) invalidates the whole record cache, which implicitly clears all the fields of the record of the onchange. The problem is that the asset is systematically invalidated by the rendering of the report itself. This hack changes the CSS assets to introduce company-specific colors for the rendering of reports. This implementation is actually not consistent with the fact that assets are kept in cache by the server. This patch does not fix the root cause of the problem, but it reduces the sides effects of it, and makes the issue above less frequent. It simply consists in not updating the asset's attachment when its value is already correct. OPW 2168623 OPW 2171040 Forward-Port-Of: odoo/odoo#44225
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#44165 Forward-Port-Of: odoo/odoo#43878
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#44165 Forward-Port-Of: odoo/odoo#43878
Steps to reproduce the problem: - Have user A with B2B group. - Have user B with B2C group. - Add simultaneously on both - via write - another group (or call `_check_one_user_type`). Expected result: - No problem Got result: - Error "A user cannot have both Tax B2B and Tax B2C..." That's because the check is performed for more than one user each time, while it has to be record per record. The implementation of `_has_multiple_groups` actually checks if the passed recordset is
Original PR description
Steps to reproduce the problem: - Have user A with B2B group. - Have user B with B2C group. - Add simultaneously on both - via write - another group (or call `_check_one_user_type`). Expected result: - No problem Got result: - Error "A user cannot have both Tax B2B and Tax B2C..." That's because the check is performed for more than one user each time, while it has to be record per record. The implementation of `_has_multiple_groups` actually checks if the passed recordset is only one record, and if not, it looks directly for all existing users, so also the case of both users A and B being in the same B2x group, but having a 3rd user in the other group will fail. Revisiting the query in `_has_multiple_groups`, there's a hidden error when you use it for only one ID because a missing space. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr cc @Tecnativa TT20968 Forward-Port-Of: odoo/odoo#43964
- Activate the VIES online check - Create a partner of type Company and add several contacts - Set the VAT number, save A call to VIES is done for each contact. The field VAT is propagated from the parent company to the children, triggering the check on all partners. This is not problematic for local checks since those are fast. However, online checks take time which can lead to a timeout of the request if there are many contacts. Since the check is triggered through a constraint (
Original PR description
- Activate the VIES online check - Create a partner of type Company and add several contacts - Set the VAT number, save A call to VIES is done for each contact. The field VAT is propagated from the…
- Activate the VIES online check - Create a partner of type Company and add several contacts - Set the VAT number, save A call to VIES is done for each contact. The field VAT is propagated from the parent company to the children, triggering the check on all partners. This is not problematic for local checks since those are fast. However, online checks take time which can lead to a timeout of the request if there are many contacts. Since the check is triggered through a constraint (`check_vat`), only one record at a time is checked. Therefore, it is not possible to build a local list of the VAT numbers to avoid duplicated verifications inside a single transaction. The solution is to store the result in cache. Since the call to the external API may fail (e.g. timeout), we extract the check to store only the successful calls. opw-2181744 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#44260 Forward-Port-Of: odoo/odoo#44160
opw-2122776 * CompAuxNum should be the code of the account concatenated with the id of the client * It should be popuated only if it is a receivable/payable The problem is the export of the partner ID in the column G "CompAuxNum". We only export the ID of the linked customer/vendor. When they import the FEC into their software to make tax declarations and annual accounts. The system will notice if an account is filled in in the column G and will override the account in column E with th
Original PR description
opw-2122776 * CompAuxNum should be the code of the account concatenated with the id of the client * It should be popuated only if it is a receivable/payable The problem is the export of the partner ID in the column G "CompAuxNum". We only export the ID of the linked customer/vendor. When they import the FEC into their software to make tax declarations and annual accounts. The system will notice if an account is filled in in the column G and will override the account in column E with the ID of the partner. As the ID is not a real account, they cannot use the FEC to import correctly. 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#43985
Forward-Port-Of: odoo/odoo#44264
Original PR description
Forward-Port-Of: odoo/odoo#44264
### Issue - Contacts - Import a contact that will be a portal user - Test import Activation email sent ### Cause Testing an import do the whole process (including sending an email) ### Solution Check if we are testing the import with a new context key import_dryrun. **OPW-2168868** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44211 Forward-Port-Of: odoo/odoo#43724
Original PR description
### Issue
- Contacts
- Import a contact that will be a portal user
- Test import
Activation email sent
### Cause
Testing an import do the whole process (including sending an email)
### Solution
Check if we are testing the import with a new context key
import_dryrun.
**OPW-2168868**
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#44211
Forward-Port-Of: odoo/odoo#43724Steps to reproduce: - install sales and contact - install another language - go to contacts, pick a specific contact and set its language to the new language installed - go to sales > settings > activate the "product configurator" option - create a product with a translated variant (the variant has to have at least 2 translated attributes with custom values) - create a quotation with the modified contact and the product with the variant (use the product configurator wizard) > save - pr
Original PR description
Steps to reproduce: - install sales and contact - install another language - go to contacts, pick a specific contact and set its language to the new language installed - go to sales > settings > activate the "product configurator" option - create a product with a translated variant (the variant has to have at least 2 translated attributes with custom values) - create a quotation with the modified contact and the product with the variant (use the product configurator wizard) > save - print that quotation Previous behavior: product description is not fully translated the part describing the variants is in the current user's language while the product display_name is using the associated partner's language Current behavior: product description is fully translated into the correct language opw-2168102 Forward-Port-Of: odoo/odoo#43846
Now, we can again creates ingenico token on production environment. Commit https://github.com/odoo/odoo/commit/f0e059e6#diff-0c487d0R558 replaced aquirer.id by self.acquire_id.id. It is wrong since env['payment.token'].create() will call the function with self == payment.token(). self.acquirer_id == False --> self.acquirer_id.state != 'enabled' --> request done in test mode each time. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior aft
Original PR description
Now, we can again creates ingenico token on production environment. Commit https://github.com/odoo/odoo/commit/f0e059e6#diff-0c487d0R558 replaced aquirer.id by self.acquire_id.id. It is wrong since env['payment.token'].create() will call the function with self == payment.token(). self.acquirer_id == False --> self.acquirer_id.state != 'enabled' --> request done in test mode each time. 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#43963
Description of the issue/feature this PR addresses: Fixes #44133 Current behavior before PR: Before this commit, the Bank account on the new Bill created from the PO was not set due to missing methods to set those fields. Desired behavior after PR is merged: This commits adds missing methods to set Bank account. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44136
Original PR description
Description of the issue/feature this PR addresses: Fixes #44133 Current behavior before PR: Before this commit, the Bank account on the new Bill created from the PO was not set due to missing methods to set those fields. Desired behavior after PR is merged: This commits adds missing methods to set Bank account. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44136
Before this commit, if you call get_alias_info with an id of group that you cannot read, it raises a traceback. It was not a problem previously since we don't handle traceback from rpc call, but now in v13 we toast it. Now, we handle the exception error in JS (cannot change controller instable) and don't toast exception. How to reproduce the bug: Drop a snippet Discussion Group Select a channel (public only are shown) Save page Edit the channel in backend and make it pri
Original PR description
Before this commit, if you call get_alias_info with an id of group that you cannot read,
it raises a traceback. It was not a problem previously since we don't handle traceback
from rpc call, but now in v13 we toast it.
Now, we handle the exception error in JS (cannot change controller instable) and don't
toast exception.
How to reproduce the bug:
Drop a snippet Discussion Group
Select a channel (public only are shown)
Save page
Edit the channel in backend and make it private
Refresh
-> a toast with an access error on the mail channel.
task-pad-feedback
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#43858Description 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#44212
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#44212
- Create and validate a leave - Go to Time Off > Everyone - In the Gantt view, move the leave Nothing prevents the modification of the leave while is it validated. opw-2179839 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#44194 Forward-Port-Of: odoo/odoo#44096
Original PR description
- Create and validate a leave - Go to Time Off > Everyone - In the Gantt view, move the leave Nothing prevents the modification of the leave while is it validated. opw-2179839 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#44194 Forward-Port-Of: odoo/odoo#44096
As this race condition seems not possible to be reproduced in local, all this is an assumption based on the logs. After the checkout, the user is redirected to `/shop/confirmation` where there is RPCs fired ever seconds to fetch the payment status (`/shop/payment/get_status`). As the test was considered as finished on that page, sometimes the RPC would still be processed in python while the tour was considered done and killed, thus also the cookies, session & co. From that point, the
Original PR description
As this race condition seems not possible to be reproduced in local, all this is an assumption based on the logs. After the checkout, the user is redirected to `/shop/confirmation` where there is RPCs fired ever seconds to fetch the payment status (`/shop/payment/get_status`). As the test was considered as finished on that page, sometimes the RPC would still be processed in python while the tour was considered done and killed, thus also the cookies, session & co. From that point, the python would crash when accessing the session. In the logs, the python crash in the RPC call occurs after the test is done. Forward-Port-Of: odoo/odoo#44222 Forward-Port-Of: odoo/odoo#44113
A payment always has a currency, which can differ from its journal's currency. We should never put the journal currency into the dictionary passed to SEPA functions. Forward-Port-Of: odoo/enterprise#8026
Original PR description
A payment always has a currency, which can differ from its journal's currency. We should never put the journal currency into the dictionary passed to SEPA functions. Forward-Port-Of: odoo/enterprise#8026
In case an invoice is having multiple tax lines, we are not correctly computing the tax balance sum. This issue was introduced with commit 3079ed1fbe1c483bfc9da6d6da4b46805b06d493. opw-2179640 Forward-Port-Of: odoo/enterprise#8020
Original PR description
In case an invoice is having multiple tax lines, we are not correctly computing the tax balance sum. This issue was introduced with commit 3079ed1fbe1c483bfc9da6d6da4b46805b06d493. opw-2179640 Forward-Port-Of: odoo/enterprise#8020