Daily updates from Odoo
Navigate
Branch
Thursday, December 12, 2019
31 changes
Enhancements to existing features
This update begins moving Odoo's mail and Discuss experience to a newer interface framework while keeping messaging responsive during loading. It should improve maintainability and prepare the product for future user-facing mail enhancements, with some visible loading behavior improvements in the messaging menu.
Sales teams can now find leads and opportunities by searching for a phone or mobile number, even if the number is typed without spaces or country-formatting symbols. This helps call center staff quickly identify a caller's open opportunities while limiting very short searches to avoid performance issues.
Original PR description
Allow users to look for leads and opportunities by using the phone number fields. This, for example, allows salesmen working in call centers to quickly retrieve all open opportunities of a specific person calling (with its phone number appearing). task-2122873
Website courses now calculate and display an estimated duration based on videos, PDFs, and manually entered slide times, excluding archived content. This helps learners understand the time commitment before starting a course, with durations shown in a clearer rounded format such as minutes or hours and minutes.
Original PR description
The duration of a course is now computed. The duration is equal the sum of the duration of all videos, plus the estimated time to read any PDF, plus the duration encoded on the other slides. The other types of slide have a field to encode the duration during its creation (not mandatory). Also, the computation take only the slides that are not archive. The format of the duration of a course on its tile is modified. It's now displayed like this : "x min" or "y hours x min". The duration displayed is also rounded to quarter of hour. Task ID : 2007294 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Subscriptions can now carry their own taxes and fiscal positions, instead of relying only on product and customer defaults. This improves invoice accuracy, renewal and upsell consistency, and TaxCloud payment flows so charged amounts better match final invoices.
Original PR description
Purpose ======= This commit introduces the notion of taxes and fiscal position in subscription models. This change was motivated by the fact that you cannot currently properly manage taxes on…
Purpose ======= This commit introduces the notion of taxes and fiscal position in subscription models. This change was motivated by the fact that you cannot currently properly manage taxes on subscriptions: if you are not in the default case where your subscription is supposed to use the default taxes from a product with the default fiscal position of the partner, you're out of luck. Unlike sale, purchase, account, etc. where you can override the defaults - this was a serious limitation. In addition, this change was also motivated by the fact that the integration with TaxCloud of the subscription module was hastily put together to counteract some nasty side-effects (e.g. a payment is done in automated processing mode but upon validation of the invoice, taxes sent by taxcloud change - the amount you just authorized on the payment method no longer matches the invoice you're trying to pay). Specifications ============== For consistency across modules, this borrows most of the logic from the sale module. - `sale.subscription.line` gets a m2m tax field as well as stored computed fields for untaxed, taxed and total prices - `sale.subscription` gets a fiscal position as well as stored computed fields for untaxed, taxed and total prices - taxes and fiscal position are forwarded from the initial SO upon creation *AND* upon renewal and upsell - taxes and fiscal position are forward upon invoice generation Migration Strategy ================== 1/ Add *default taxes* based on the product and partner (*do not* try to guess the taxes from the initial SO - existing subscriptions have been generating invoices with the default taxes prior to this, making this a mandatory choice for the migration) 2/ Recompute totals for lines This recomputation should not be done in SQL, since it is based on taxes that could be included or excluded, fiscal position mapping, currency rounding and the like. Use Python code to do this. A possible strategy to improve perfs should we need to (although I do not expect a lot of database with *millions* of subscriptions to actually exist) is similar to what we did in v12 for `pos.order.line` - categorizing all lines according to a unique set of properties that entirely define the tax and totals computations, compute totals for one sample line and push the result on the whole set. 3/ Recompute totals for subscriptions Quite simple since all underlying data was computed in the previous step, unless round globally is active in the db, can most probably be summed in SQL from the lines directly. Task-1974609
The wording for a financial reporting date option has been clarified so users better understand what the "normal" setting means. This helps avoid confusion with strict date range behavior when configuring or reviewing account reports.
Original PR description
Just to make it clear that it's not equivalent to strict_range.
Resolved issues and error corrections
This fixes a small issue caused by a previous web client test change that accidentally removed behavior still needed by Enterprise. Restoring the startup flag helps ensure related automated tests and Enterprise web behavior continue to work as expected.
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
This update removes or adjusts unstable automated tests that could pass or fail unpredictably. It helps the development team get more trustworthy test results, reducing false alarms and improving confidence in future changes.
Original PR description
this test needs to wait to 2 nextTick (nextAnimationFrame) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures Odoo tracks check numbers in a numeric format as well as text, so the next check number is calculated correctly. Businesses paying vendor bills by check will see the proper next number instead of the widget repeatedly showing 1.
Original PR description
Go to Accounting > Vendor Bill, pay via check, view the invoice and click on 'Print Check'. The widget will popup but as the 'next check number' will always display 1. This append because the model of account_payment has changed https://github.com/odoo/odoo/blob/13.0/addons/account_check_printing/models/account_payment.py#L28 and now check_number is a char so it will not sorted correcly by the database. To avoid doing a lot of strings manipulation it is convenient to store the check number as integer, with proper default case Followup of opw 2151242 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix clarifies how pivot table header clicks are detected in the web interface. It helps maintain reliable pivot table behavior and reduces the risk of future regressions when users interact with reports.
Original PR description
This commit explains why we use isHeaderClicked. 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
Selecting a reconciliation model during manual reconciliation now works without triggering an error caused by missing currency information. This prevents interruptions for accounting users and keeps the reconciliation workflow usable.
Original PR description
Before that, an empty account.bank.statement.line recordset was passed to the function, and caused the recordset containing the currency to use to also be empty, eventually leading to a rounding value of 0, which raised and error.
Code cleanup and technical improvements
This change adds dedicated eLearning Officer and Manager roles so course administration can be assigned separately from general website editing. It gives businesses more precise control over who can create, publish, manage, or delete courses and learning content, while preserving existing course responsibility workflows.
Original PR description
### Purpose Have user groups specific to eLearning to separate them from generic website editors. Indeed this is a specific work area and require more than pure design skill. ### Details Two user…
### Purpose
Have user groups specific to eLearning to separate them from generic website
editors. Indeed this is a specific work area and require more than pure design
skill.
### Details
Two user groups has been added:
* group_website_slides_officer
\+ can read any course/slide
\+ can create a course
\+ can add slide to the courses he is responsible
\+ can publish the courses/slides he is responsible
\- cannot unlink courses/slides (you should archive them)
\* implies group_website_publisher in order to see the top navbar in frontend
with the publish toggle button and the new content button.
* group_website_slides_manager
\* The Manager is an Officer with more rights.
\+ can read any course/slide
\+ can create a course
\+ can add slide to any courses
\+ can publish any courses/slides
\+ can unlink any courses/slides
When website_slides_survey is installed:
+ group_website_slides_officer implies group_survey_user
+ group_website_slides_manager implies group_survey_manager
task-2062462
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prMiscellaneous changes
Since the purchase_price is now computed, it may be triggered before an uom is set on the product line (onchanges may happen after computes). -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41798
Original PR description
Since the purchase_price is now computed, it may be triggered before an uom is set on the product line (onchanges may happen after computes). -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41798
Steps to reproduce: -install accounting -go to settings > accounting > check the 'Analytic Tags' and the 'Analytic Accounting' options -go to accounting > configuration > analytic tags and try to use the search => You should be unable to search tags by name (working in 12.0) Previous behavior: searching tags by name is not possible Current behavior: searching tags works as intended and allows to filter by tag name opw-2152154 Forward-Port-Of: odoo/odoo#41786
Original PR description
Steps to reproduce: -install accounting -go to settings > accounting > check the 'Analytic Tags' and the 'Analytic Accounting' options -go to accounting > configuration > analytic tags and try to use the search => You should be unable to search tags by name (working in 12.0) Previous behavior: searching tags by name is not possible Current behavior: searching tags works as intended and allows to filter by tag name opw-2152154 Forward-Port-Of: odoo/odoo#41786
…mers Steps to reproduce: - install the POS module - install the Contacts module Previous behavior After ending a POS session, partners that are created and/or used during the session are not showing on the Contacts views when the 'customer' filter is active Current behavior: Partners created or linked during a POS session are considered customers and appear in the contact view when the "customer" filter is active opw-2148894 Forward-Port-Of: odoo/odoo#41767 Forward-Port-Of:
Original PR description
…mers Steps to reproduce: - install the POS module - install the Contacts module Previous behavior After ending a POS session, partners that are created and/or used during the session are not showing on the Contacts views when the 'customer' filter is active Current behavior: Partners created or linked during a POS session are considered customers and appear in the contact view when the "customer" filter is active opw-2148894 Forward-Port-Of: odoo/odoo#41767 Forward-Port-Of: odoo/odoo#41567
In v13, the `stock.inventory` model has been replaced by a view on the quants. However, importing is not possible since most fields are `readonly`. We make the fields writable in the model and protect them in the view. However, this only works in SUPERUSER, since the ACL are limited to read-only. opw-2128053 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
Original PR description
In v13, the `stock.inventory` model has been replaced by a view on the quants. However, importing is not possible since most fields are `readonly`. We make the fields writable in the model and protect them in the view. However, this only works in SUPERUSER, since the ACL are limited to read-only. opw-2128053 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#41780
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#41626 Forward-Port-Of: odoo/odoo#41335
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#41626 Forward-Port-Of: odoo/odoo#41335
Forward-Port-Of: odoo/odoo#41733 Forward-Port-Of: odoo/odoo#41650
Original PR description
Forward-Port-Of: odoo/odoo#41733 Forward-Port-Of: odoo/odoo#41650
12:00 AM is midnight and 12:00 PM is noon. opw-2154640 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#41747 Forward-Port-Of: odoo/odoo#41743
Original PR description
12:00 AM is midnight and 12:00 PM is noon. opw-2154640 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#41747 Forward-Port-Of: odoo/odoo#41743
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#41315 Forward-Port-Of: odoo/odoo#41298
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#41315 Forward-Port-Of: odoo/odoo#41298
As the field isn't mandatory, avoid the `TypeError: 'bool' object is not subscriptable` error. Forward-Port-Of: odoo/odoo#41699
Original PR description
As the field isn't mandatory, avoid the `TypeError: 'bool' object is not subscriptable` error. Forward-Port-Of: odoo/odoo#41699
Install POS, create a product available in POS, tracked by Serial Number. Add some product to the inventory. Open the POS session, sell the demo item, close the session (do not end the session, just close the interface). Go to POS orders, select the last order and click on "Return Products", the refund will be created. The user will be unable to process payment for the refund order because Serial Number is missing. Adding a copy of the lot from the original order line fix the issue
Original PR description
Install POS, create a product available in POS, tracked by Serial Number. Add some product to the inventory. Open the POS session, sell the demo item, close the session (do not end the session, just close the interface). Go to POS orders, select the last order and click on "Return Products", the refund will be created. The user will be unable to process payment for the refund order because Serial Number is missing. Adding a copy of the lot from the original order line fix the issue opw-2152776 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41696
Deleting a payment will prevent the POS session closing. opw-2155093 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#41744
Original PR description
Deleting a payment will prevent the POS session closing. opw-2155093 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#41744
PURPOSE This commit 62ac23f introduced SMS capabilities on for event.type.mail and event.mail models. Values of event_type_mail_ids on event.type are supposed to be copied to event_mail_ids on event.event when changing the event_type_id of an event.event (if you follow me). There were, however, 2 issues with that integration: - The 'notification_type' field was not correctly set on default event_type_mail_ids on event.type - The 'notification_type' and 'sms_template' fields were n
Original PR description
PURPOSE This commit 62ac23f introduced SMS capabilities on for event.type.mail and event.mail models. Values of event_type_mail_ids on event.type are supposed to be copied to event_mail_ids on event.event when changing the event_type_id of an event.event (if you follow me). There were, however, 2 issues with that integration: - The 'notification_type' field was not correctly set on default event_type_mail_ids on event.type - The 'notification_type' and 'sms_template' fields were not copied from event_type_mail_ids to event_mail_ids LINKS PR #39892 Task#2115792 Forward-Port-Of: odoo/odoo#39892
Before this change, it was not possible to a user to change its own language via the Preference view. In order to allow a user who does not have access rights on the res.users model to modify his language (field included in the list of SELF_WRITEABLE_FIELDS fields) it is necessary to force the reandly attribute to False in the view used to edit the user's preferences. opw-2151630 Closes #41412 Description of the issue/feature this PR addresses: Current behavior before PR: Des
Original PR description
Before this change, it was not possible to a user to change its own language via the Preference view. In order to allow a user who does not have access rights on the res.users model to modify his language (field included in the list of SELF_WRITEABLE_FIELDS fields) it is necessary to force the reandly attribute to False in the view used to edit the user's preferences. opw-2151630 Closes #41412 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#41742
Forward-Port-Of: odoo/enterprise#6446
Original PR description
Forward-Port-Of: odoo/enterprise#6446
…nd payment When, in mexican accounting, an invoice is validated in a currency different from Mexican dollars, and then its related payment is done (also in a currency different from mexican dollars) and signed, the change rate recorded in the XML are different, as one is rounded and the other is not. opw-2079978 Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com> Forward-Port-Of: odoo/enterprise#7220 Forward-Port-Of: odoo/enterprise#7140
Original PR description
…nd payment When, in mexican accounting, an invoice is validated in a currency different from Mexican dollars, and then its related payment is done (also in a currency different from mexican dollars) and signed, the change rate recorded in the XML are different, as one is rounded and the other is not. opw-2079978 Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com> Forward-Port-Of: odoo/enterprise#7220 Forward-Port-Of: odoo/enterprise#7140
…fund The comptapocalypse made OCR available on out_refund and out_invoice, that is not the normal use case. This commit remove the functionality to send invoice to OCR service in this case Forward-Port-Of: odoo/enterprise#7223
Original PR description
…fund The comptapocalypse made OCR available on out_refund and out_invoice, that is not the normal use case. This commit remove the functionality to send invoice to OCR service in this case Forward-Port-Of: odoo/enterprise#7223
Purpose ====== Clean dead code Specification ========== Remove unused controller/main.py file in website_crm_score. This file is not loaded anymore since introduction of website_visitor. Before website_visitor introduction, when a contact form was sent: - if a lead existed already, the lead was updated with the given form values. - if not, a new lead was created and all the page views was linked to that lead. After website_visitor introduction, when a contact form is sent:
Original PR description
Purpose ====== Clean dead code Specification ========== Remove unused controller/main.py file in website_crm_score. This file is not loaded anymore since introduction of website_visitor. Before website_visitor introduction, when a contact form was sent: - if a lead existed already, the lead was updated with the given form values. - if not, a new lead was created and all the page views was linked to that lead. After website_visitor introduction, when a contact form is sent: - A new lead is created anyway and linked to the visitor. - If a contact form is sent once again, a new lead is created and linked to the same visitor. - Page views are linked to the visitor - In lead view, we can see all page views from the linked visitor Task ID: 2153971 Forward-Port-Of: odoo/enterprise#7198
Forward-Port-Of: odoo/enterprise#7203
Original PR description
Forward-Port-Of: odoo/enterprise#7203
There are two invoice statuses in the response: - status: status of Carvajal (invoice processing 3rd party) - legalStatus: status of DIAN (government) All combinations of the statuses happen, even though it seems weird at first (not accepted for Carvajal, but accepted according to the government). The best way to handle all cases is to look at the legal status as soon as Carvajal finishes processing it. This is the legally binding status. opw-2154293 Forward-Port-Of: odoo/enter
Original PR description
There are two invoice statuses in the response: - status: status of Carvajal (invoice processing 3rd party) - legalStatus: status of DIAN (government) All combinations of the statuses happen, even though it seems weird at first (not accepted for Carvajal, but accepted according to the government). The best way to handle all cases is to look at the legal status as soon as Carvajal finishes processing it. This is the legally binding status. opw-2154293 Forward-Port-Of: odoo/enterprise#7213
Forward-Port-Of: odoo/enterprise#7028 Forward-Port-Of: odoo/enterprise#7018
Original PR description
Forward-Port-Of: odoo/enterprise#7028 Forward-Port-Of: odoo/enterprise#7018