Monday, June 20, 2022
34 changes · master
Enhancements to existing features
This update makes internal test data creation more explicit by replacing empty record creation calls with clearly empty values. It helps keep development and testing behavior consistent while preparing to remove an unsupported shortcut, with no expected impact on everyday users.
Original PR description
\* mail, test_mail_full, website_livechat
**Current behavior before PR:**
Creating a record with no values has no sense but is sometimes useful during
tests.
The support should be dropped for `default` parameter in `create`.
**Desired behavior after PR is merged:**
All the occurrences of `create()` have been replaced by `create({})`.
Task-2869394
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects wording in the Accounting app from “digitalization” to “digitization” when referring to extracting data from documents. It improves clarity and uses the more accurate business term, with no expected change to functionality.
Original PR description
The correct word for the extraction of data from a document is digitization, not digitalization. See feedback #2862606.
This update streamlines how attachments are managed and shared across Odoo messaging areas, including Discuss, Live Chat, Portal, and ratings. It reduces reliance on older attachment handling paths, making message-related features more consistent and easier to maintain without changing core business workflows.
Original PR description
Part of task-2886642
The website live chat module now separates the chatbot server URL handling, making chatbot conversations easier to configure and maintain. This helps improve reliability for visitor chat interactions without changing the overall user experience.
Original PR description
Task-2883598
The live chat module has been updated to better organize how the chat button and initialization process work. This should make the website chat experience easier to maintain and more reliable for future improvements, with limited direct impact on daily users.
Original PR description
Task-2888551
The live chat experience now has a clearer default visitor name available through the chat button view. This helps keep conversations easier to identify when visitors have not provided their own name.
Original PR description
Task-2884731
This update renames accounting security access rights to make permissions easier to understand and manage. It also clarifies a Colombian electronic invoicing company registry label to avoid duplicate wording, reducing confusion for administrators.
Original PR description
This PR: - renames the security access rights Task-id: 2857253 Community PR: https://github.com/odoo/odoo/pull/91938
This update simplifies how attachments are loaded and previewed in enterprise mail and accounting-related screens. It removes outdated internal options and updates tests, helping keep document workflows more reliable as the interface framework evolves.
Original PR description
Part of task-2886642
The Gantt view now shows a clearer notification when users try to automatically reschedule tasks that are already in the past. This helps users understand that those tasks need manual rescheduling instead of leaving the system behavior ambiguous.
Original PR description
Purpose of this PR to improve generic usage of project app. So, in this PR done following changes: - changed toast notification in project.task gantt view task-2806292
User-facing wording in document extraction features now uses “digitization” instead of “digitalization.” This improves terminology accuracy and consistency across invoice and expense extraction screens and messages.
Original PR description
The correct word for the extraction of data from a document is digitization, not digitalization. See feedback #2862606.
The test code now uses an explicit empty value when creating records, matching the newer expected behavior. This is an internal cleanup that helps keep automated tests reliable and aligned with platform conventions, with no expected impact on day-to-day users.
Original PR description
**Current behavior before PR:**
Creating a record with no values has no sense but is sometimes useful during
tests.
The support should be dropped for the `default` parameter in `create`.
**Desired behavior after PR is merged:**
All the occurrences of `create()` have been replaced by `create({})`.
Task-2869394
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prResolved issues and error corrections
Follower notification options in Mail are now shown in the same consistent order across the interface. This makes subscription settings easier to understand and prevents confusing differences caused by items appearing in an arbitrary order.
Original PR description
Before this fix, follower subtypes were displayed by order of id, whereas in DiscussController.read_subscription_data(), it was ordered by : \- parent_mode \- res_mode \- internal \- sequence See : https://github.com/odoo/odoo/blob/fc115ebdf7c3783f9eaabba71eccce23c676d957/addons/mail/controllers/discuss.py#L471-472 In this commit, we just reproduce the same order. Also, for `parentModel` and `resModel`, we want the record with their values unset to come first. We added 'undefined-first', as this sort order might be needed for other models. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
Barcode scanning now relies on one consistent keyboard event instead of switching between multiple event types. This simplifies the underlying code, making barcode behavior easier to maintain and reducing the chance of future inconsistencies without changing the user workflow.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Description of the issue/feature this PR addresses: 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#93921
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#93921
A spelling mistake in the employee referral settings screen was corrected. This improves clarity for users configuring the referral app without changing any business process or feature behavior.
Original PR description
taskID 2879618
The public website live chat code was reorganized to align with Odoo's newer messaging framework. This is mainly an internal improvement that should make future live chat enhancements easier and more consistent, with limited immediate impact for end users.
Original PR description
*: website_livechat This commit is a step towards refactoring the JS of public livechat, so that it reuses the same architecture as the code of Discuss. This implies code that uses JS models and OWL components. Task-2888734
This reverts commit 65b5ec4ad65f798b1d647978b5b42a49e760139a. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93518 Forward-Port-Of: odoo/odoo#93262
Original PR description
This reverts commit 65b5ec4ad65f798b1d647978b5b42a49e760139a. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93518 Forward-Port-Of: odoo/odoo#93262
Until know, Transifex projects were organised as: - odoo-14 - odoo-15 - odoo-master with odoo-master changing frenquently to reflect the last used saas version, to prepare the future odoo-16 version. This was ok as most people used stable versions at that time. Now the saas versions are frequently released and many users of odoo.com are running these versions, the quality of translations is more important and preparing for the future version is not the only goal. Having only o
Original PR description
Until know, Transifex projects were organised as: - odoo-14 - odoo-15 - odoo-master with odoo-master changing frenquently to reflect the last used saas version, to prepare the future odoo-16 version.…
Until know, Transifex projects were organised as: - odoo-14 - odoo-15 - odoo-master with odoo-master changing frenquently to reflect the last used saas version, to prepare the future odoo-16 version. This was ok as most people used stable versions at that time. Now the saas versions are frequently released and many users of odoo.com are running these versions, the quality of translations is more important and preparing for the future version is not the only goal. Having only one project synchronised with a saas version is not enough as we frenquently have to support multiple versions in parallel (e.g. saas-15.2 for users and saas-15.3 for odoo.com). Switch to a project for each saas release to be more flexible. Hopefully, it won't be too much additional work for translators thanks to TM. New organisation: - odoo-14 - odoo-15 - odoo-s15-2 - odoo-s15-3 and delete projects when it is no longer supported Forward-Port-Of: odoo/odoo#93972 Forward-Port-Of: odoo/odoo#93890
Small improvements: UI and allow view override. taskid: 2855699 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93197 Forward-Port-Of: odoo/odoo#92732
Original PR description
Small improvements: UI and allow view override. taskid: 2855699 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93197 Forward-Port-Of: odoo/odoo#92732
Steps to reproduce: 1- install sales ,accounting, project, timesheets 2- create a new service product p1 that triggers a project and a task 3- create a new sales order so with p1 and validate 1 hour in the task 4- create an invoice from so, an anayltic account is added 5- edit any field of product_id, account_id, partner_id, date 6- the analytic default rule is applied (in this case none) so the anayltic account is removed Bug: the `compute_analytic_account_id` method forces the a
Original PR description
Steps to reproduce: 1- install sales ,accounting, project, timesheets 2- create a new service product p1 that triggers a project and a task 3- create a new sales order so with p1 and validate 1 hour in the task 4- create an invoice from so, an anayltic account is added 5- edit any field of product_id, account_id, partner_id, date 6- the analytic default rule is applied (in this case none) so the anayltic account is removed Bug: the `compute_analytic_account_id` method forces the analytic default rule even if the field is already set before the changes Fix: apply analytic default rule only if the analytic acount is not set and if it is not a project generated move OPW-2833912 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#93965 Forward-Port-Of: odoo/odoo#92440
SHA1 is going to be deprecated by ogone. This change try to keep current behaviour while adding the possibility to use SHA256 and SHA512 As this change as to be done in stable version, We use the length of the key to know which version of SHA we should use. The goal is to switch add an selection to master to ensure better code modularity. The change was requested by PDE/ANV. opw-2766648 X-original-commit: b0df4af -- I confirm I have signed the CLA and read the PR guidel
Original PR description
SHA1 is going to be deprecated by ogone. This change try to keep current behaviour while adding the possibility to use SHA256 and SHA512 As this change as to be done in stable version, We use the length of the key to know which version of SHA we should use. The goal is to switch add an selection to master to ensure better code modularity. The change was requested by PDE/ANV. opw-2766648 X-original-commit: b0df4af -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93894
Steps to reproduce the bug: - Go to inventory > reporting > inventory report - Add any “group by”, for example: ‘product’ - Click on the “Apply All” button Problem: A Missing record error is triggered. When we click on the button, the `active_ids` key is added in the context, but it does not represent the ids of the `stock.quant` but rather the ids of the grouped records, "product" in our case: https://github.com/odoo/odoo/blob/bec3c58df303df6ac508bdfbb9b317d5019b858a/addons/stock/st
Original PR description
Steps to reproduce the bug: - Go to inventory > reporting > inventory report - Add any “group by”, for example: ‘product’ - Click on the “Apply All” button Problem: A Missing record error is…
Steps to reproduce the bug: - Go to inventory > reporting > inventory report - Add any “group by”, for example: ‘product’ - Click on the “Apply All” button Problem: A Missing record error is triggered. When we click on the button, the `active_ids` key is added in the context, but it does not represent the ids of the `stock.quant` but rather the ids of the grouped records, "product" in our case: https://github.com/odoo/odoo/blob/bec3c58df303df6ac508bdfbb9b317d5019b858a/addons/stock/static/src/js/inventory_singleton_list_controller.js#L127 Then, They are added in the context of the wizard with the key: `default_quant_ids`: https://github.com/odoo/odoo/blob/262b49d85a95bc445e954741224305ebaa7f545b/addons/stock/wizard/stock_inventory_adjustment_name.xml#L27-L28 So when we get the `stock.quant` records, we do a search with the ids of the products instead of the `stock.quant` https://github.com/odoo/odoo/blob/8f12dbc00fdc96732fd2ec9104ed6bf057327ef4/addons/stock/wizard/stock_inventory_adjustment_name.py#L14 Therefore, if there is no `stock.quant` with the same id as the products, an error will be thrown opw-2879590 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93723
Steps to reproduce: -Install sales and crm -Apply multiteam option in crm settings -Create a user with two teams A and B -Create with this user a lead with team B -From this lead create a quotation Current behavior: The quotation could have team A (the team of the lead is ignored) Expected behavior: The quotation always has team B Problem when creating the quotation the team id is not propagated in the context to the final function _get_default_team_id and in this function the
Original PR description
Steps to reproduce: -Install sales and crm -Apply multiteam option in crm settings -Create a user with two teams A and B -Create with this user a lead with team B -From this lead create a quotation…
Steps to reproduce:
-Install sales and crm
-Apply multiteam option in crm settings
-Create a user with two teams A and B
-Create with this user a lead with team B
-From this lead create a quotation
Current behavior:
The quotation could have team A (the team of the lead is ignored)
Expected behavior:
The quotation always has team B
Problem when creating the quotation the team id is not propagated
in the context to the final function _get_default_team_id and in
this function the default context team is only check if no teams
have been found for the user, so the function always selects the
first team of the user. To solve the issue we propagate the team
id to the default function and we change it so that if the context
default team is in the user teams it is this one that is going to
be selected and no other.
Small behavior change:
Two cases are added in the _get_default_team_id function that slightly change
the current behavior. For the two first cases instead of just choosing any team in
the list we add a case so that IF there is a default team in the context AND that this
team is in the list then its going to be this one that's gonna be selected. See function
comments:
1- any of my teams (member OR responsible) matching domain
2- any of my teams (member OR responsible)
becomes
1- default from context if in my teams (member OR responsible) matching domain
2- any of my teams (member OR responsible) matching domain
3- default from context if in any of my teams (member OR responsible)
4- any of my teams (member OR responsible)
opw-2830913
Task-2852947
Forward-Port-Of: odoo/odoo#93896
Forward-Port-Of: odoo/odoo#90289The condition to display the start event warning in the track view was that the event was not ongoing. This fix adds the condition that the event is upcoming, preventing the warning to be displayed after the event date. Task-2692907 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#90948
Original PR description
The condition to display the start event warning in the track view was that the event was not ongoing. This fix adds the condition that the event is upcoming, preventing the warning to be displayed after the event date. Task-2692907 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#90948
This commit addresses several issues: 1. The overwrite of `_recompute_completion` was not properly filtering the partners that had actually completed the course. meaning that passing through this function could add a course/slide.channel as an employee skill iven if they did not complete it. Now, we only act upon employees that have actually finished the course. 2. The function would add the same skill over and over again, assuming that we could only pass through it once but it is act
Original PR description
This commit addresses several issues: 1. The overwrite of `_recompute_completion` was not properly filtering the partners that had actually completed the course. meaning that passing through this…
This commit addresses several issues: 1. The overwrite of `_recompute_completion` was not properly filtering the partners that had actually completed the course. meaning that passing through this function could add a course/slide.channel as an employee skill iven if they did not complete it. Now, we only act upon employees that have actually finished the course. 2. The function would add the same skill over and over again, assuming that we could only pass through it once but it is actually called every time we publish or archive any slide of a course since 9920f20e. This can lead to a bit of bloat on an employee resume (See task attachments). Now, we try to make the function idempotent and only add a resumé line only once. 3. The addition of a resume line could not be achieved and would raise an ACL when the current user was not an HR Officer (group `hr_user`). Since it can be called by any eLearning(`slides`) manager, a sudo privilege is necessary. Related Task: 2830016 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#94019 Forward-Port-Of: odoo/odoo#93555
Steps to reproduce: - Install project and timesheet - Create a project with settings "invited employees only" - Create a user with administrator project right (and non admin rights for timesheet) - Create a task in the new project - Try to generate a timesheet on the task with the new user (the user has to not follow the task) Current behavior: This generate an access error due to not respecting some rules Expected behavior: The timesheet is created Explanation: The project ad
Original PR description
Steps to reproduce: - Install project and timesheet - Create a project with settings "invited employees only" - Create a user with administrator project right (and non admin rights for timesheet) - Create a task in the new project - Try to generate a timesheet on the task with the new user (the user has to not follow the task) Current behavior: This generate an access error due to not respecting some rules Expected behavior: The timesheet is created Explanation: The project admin should be able to handle any timesheet that is linked to a project to do so we add its group to the rule that gives access to the model analytic.model_account_analytic_line if there is a project_id. The steps to reproduce creates a situation where the timesheet_line_rule_approver is not respected anymore so by adding this group rule the timesheet_line_rule_approver does not have to be respected anymore. opw-2861042 Forward-Port-Of: odoo/odoo#92771
before this commit: Using the `neutralize` cli tool would not neutralise onss related fields on the companies, potentially resulting in valide requests to be sent to the authorities in test databases. Forward-Port-Of: odoo/enterprise#28604 Forward-Port-Of: odoo/enterprise#28442
Original PR description
before this commit: Using the `neutralize` cli tool would not neutralise onss related fields on the companies, potentially resulting in valide requests to be sent to the authorities in test databases. Forward-Port-Of: odoo/enterprise#28604 Forward-Port-Of: odoo/enterprise#28442
The Follow-up reports use the Accounting Date in their custom display. This is incorrect and should use the Invoice Date. While they're almost always the same, in the case of locked periods, they can differ. In any case, the Invoice Date should be used as it's the only date that makes sense for the customer. Task : [2848082](https://www.odoo.com/web#id=2848082&menu_id=3940&cids=1&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#27524
Original PR description
The Follow-up reports use the Accounting Date in their custom display. This is incorrect and should use the Invoice Date. While they're almost always the same, in the case of locked periods, they can differ. In any case, the Invoice Date should be used as it's the only date that makes sense for the customer. Task : [2848082](https://www.odoo.com/web#id=2848082&menu_id=3940&cids=1&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#27524
How to reproduce the bug ? - install account_accountant, l10n_co, l10n_co_edi - follow the procedure to test l10n_co (https://docs.google.com/document/d/167i3L1_AKV-6VS8yYevYaObja24Sx5NZ8klTg7eUWjg) - Go to Accounting > Configuration > Taxes and click on the one called "IVA Ventas 19%" - Change the field "Tax Computation" to "Fixed", (in "Advanced Options") "Tax Group" to "IC" and "Tipo de Valor" to "IC". Save the modification. - Go to Customers > Invoices and create a new invoice. -
Original PR description
How to reproduce the bug ? - install account_accountant, l10n_co, l10n_co_edi - follow the procedure to test l10n_co (https://docs.google.com/document/d/167i3L1_AKV-6VS8yYevYaObja24Sx5NZ8klTg7eUWjg)…
How to reproduce the bug ? - install account_accountant, l10n_co, l10n_co_edi - follow the procedure to test l10n_co (https://docs.google.com/document/d/167i3L1_AKV-6VS8yYevYaObja24Sx5NZ8klTg7eUWjg) - Go to Accounting > Configuration > Taxes and click on the one called "IVA Ventas 19%" - Change the field "Tax Computation" to "Fixed", (in "Advanced Options") "Tax Group" to "IC" and "Tipo de Valor" to "IC". Save the modification. - Go to Customers > Invoices and create a new invoice. - Pick the customer you have modified in the test procedure and add a product to the invoice. - Save and Confirm the invoice. What is the bug ? With a colombian company, when you create an invoice with a product with a fixed value tax you will get an error on confirmation. This is due to the fact that the method computing the taxes (_l10n_co_edi_get_round_amount) doesn't work with the value specified with a fixed value. opw-2883894 Signed-off-by: Adrien Minet <admi@odoo.com> Forward-Port-Of: odoo/enterprise#28541
Add a clear error message. Task: 2822469 Currently, all fields of LU reports are only validated with XSD. The error messages that are raised by XSD validation can be unclear. Should be: most important fields, such as company's VAT, ECDF, and Matr. numbers should be validated separately to raise a more user-friendly error. Forward-Port-Of: odoo/enterprise#28534 Forward-Port-Of: odoo/enterprise#26267
Original PR description
Add a clear error message. Task: 2822469 Currently, all fields of LU reports are only validated with XSD. The error messages that are raised by XSD validation can be unclear. Should be: most important fields, such as company's VAT, ECDF, and Matr. numbers should be validated separately to raise a more user-friendly error. Forward-Port-Of: odoo/enterprise#28534 Forward-Port-Of: odoo/enterprise#26267
This is the follow up of https://github.com/odoo/enterprise/pull/26152 taskid: 2855699 Forward-Port-Of: odoo/enterprise#28195 Forward-Port-Of: odoo/enterprise#27491
Original PR description
This is the follow up of https://github.com/odoo/enterprise/pull/26152 taskid: 2855699 Forward-Port-Of: odoo/enterprise#28195 Forward-Port-Of: odoo/enterprise#27491
Until know, Transifex projects were organised as: - odoo-14 - odoo-15 - odoo-master with odoo-master changing frenquently to reflect the last used saas version, to prepare the future odoo-16 version. This was ok as most people used stable versions at that time. Now the saas versions are frequently released and many users of odoo.com are running these versions, the quality of translations is more important and preparing for the future version is not the only goal. Having only o
Original PR description
Until know, Transifex projects were organised as: - odoo-14 - odoo-15 - odoo-master with odoo-master changing frenquently to reflect the last used saas version, to prepare the future odoo-16 version.…
Until know, Transifex projects were organised as: - odoo-14 - odoo-15 - odoo-master with odoo-master changing frenquently to reflect the last used saas version, to prepare the future odoo-16 version. This was ok as most people used stable versions at that time. Now the saas versions are frequently released and many users of odoo.com are running these versions, the quality of translations is more important and preparing for the future version is not the only goal. Having only one project synchronised with a saas version is not enough as we frenquently have to support multiple versions in parallel (e.g. saas-15.2 for users and saas-15.3 for odoo.com). Switch to a project for each saas release to be more flexible. Hopefully, it won't be too much additional work for translators thanks to TM. New organisation - odoo-14 - odoo-15 - odoo-s15-2 - odoo-s15-3 and delete projects when it is no longer supported Forward-Port-Of: odoo/enterprise#28568 Forward-Port-Of: odoo/enterprise#28531
Fix the issue that product version not updated correctly Forward-Port-Of: odoo/enterprise#28546
Original PR description
Fix the issue that product version not updated correctly Forward-Port-Of: odoo/enterprise#28546
before this commit: No _neutralize method existed for `amazon.account` which made the use of the `neutralize` cli tool incomplete Forward-Port-Of: odoo/enterprise#28431 Forward-Port-Of: odoo/enterprise#28382
Original PR description
before this commit: No _neutralize method existed for `amazon.account` which made the use of the `neutralize` cli tool incomplete Forward-Port-Of: odoo/enterprise#28431 Forward-Port-Of: odoo/enterprise#28382