Thursday, October 28, 2021
33 changes · master
New functionality added to Odoo
The DIN 5008 business document layout has been separated from the German localization so it can also be used for Switzerland and Austria. This makes compliant document formatting available to more countries without requiring the German localization module.
Original PR description
DIN 5008 is not specific to Germany. It also applies to Switzerland, Austria (& Lichtenstein). The goal is to make DIN independent from l10n_de, for Switzerland and Austria. Task: 2613993
Enhancements to existing features
The stock app now shows the correct warning when a product putaway rule is affected by a company change. This avoids confusing users with a message that referred to an unavailable field, making company-related stock configuration easier to understand.
Original PR description
Fixes #75608 We don't have active field on `stock.putaway.rule`. 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
Resolved issues and error corrections
This fixes an inconsistency in how a setting for visual effects was interpreted, ensuring it is always handled as a simple on/off value. The change helps avoid unpredictable behavior in the user interface and setup configuration.
Miscellaneous changes
commit 96b56ea fix the link between SO <-> MO in manufacture 3 steps but break it on other configuration It happens because without `store after manufacturing` the procurement group is not copied and used on the MO. And the stat button search on procurement group with a MO and a SO on it. Before it was searching on `stock_move.created_production_id` and thus was able to find the MO. This commit do a mix of the 2 solutions. It search for procurement group linked to SO and MO + created_
Original PR description
commit 96b56ea fix the link between SO <-> MO in manufacture 3 steps but break it on other configuration It happens because without `store after manufacturing` the procurement group is not copied and used on the MO. And the stat button search on procurement group with a MO and a SO on it. Before it was searching on `stock_move.created_production_id` and thus was able to find the MO. This commit do a mix of the 2 solutions. It search for procurement group linked to SO and MO + created_production_id to be sure to find all the MO related to a SO opw-2645042 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#79038 Forward-Port-Of: odoo/odoo#79015
Employees can now cancel their own approved time off without needing Time Off administrator rights, as long as the leave has not started and no work entries have been generated. This makes schedule corrections faster while automatically restoring the allocated days and archiving the cancelled request.
Original PR description
A user without Time Off rights is now allowed to cancel their own
validated time off when:
- It's not yet started;
- No work-entries has been generated for it yet.
The time off is archived and the days taken reallocated.
TaskID: 2643713
Related: odoo/upgrade#2843
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-prThis update improves project management usability across projects, tasks, timesheets, portal pages, ratings, and related sales flows. Users get clearer project status and satisfaction indicators, better navigation and reporting views, improved access to milestones, and more accurate linked sales order information.
Original PR description
Adds multi record support to `_show_report`. Limited to records within the same company to stay as close as possible to the default behaviour. Adds the satisfaction percentage as an optional compute…
Adds multi record support to `_show_report`. Limited to records within the same company to stay as close as possible to the default behaviour. Adds the satisfaction percentage as an optional compute to `rating.mixin`. Smaller changes: - Projects created on the fly (through `name_create`) will now come with a default `new` stage in order for them to not be empty. - Removed task auto assign upon creation besides in FSM's 'My tasks' menu. - Allow the reordering of projects without needing to group by anything. - Make `project.task`.`description` and `project.tags`.`name` translatable. - Disable the creation of records in the view when clicking on `Tasks in recurrence` stat button. - Track the planned date of the task in the chatter - Disable the creation of records in the view when clicking on 'invoices' stat button and add the kanban view to that action. - Make milestones completely available to regular project users. - Remove the 'Documents' button in the project's kanban settings menu. - Add kanban, pivot and graph views to the 'Hours Recorded' stat button on projects - Add the calendar view on the 'Hours Forecast' stat button on projects - The 'Sales Orders' stat button on the `project.project`'s form view will now display the amount of sales order linked to the whole project. So the one linked to the project itself if it exists + all the tasks. It will also open them, form view if 1 else list view. - Fix a typo in the settings 'projets' => 'projects' - The analytic account of the project will now be assigned to the sales order when a task is created through the 'Create a task in an existing project' option. Changed the portal task view to include a sidebar similar to sales orders, with a simple menu leading to different parts of the screen. Changed the `project.task` 'rating' stat button: - The icon will now represent the latest review. - The action will directly lead to the record's form view if there is only 1 rating. - Make some fields readonly in the form view. - Display the % of satisfaction instead of the number of ratings. Reorder all stat buttons on the `project.task` form view in this order: - Products, Worksheet, Sales Order(s), Invoices, Ratings, Hours Forecast, Parent Task, Tasks in recurrence, Tickets, Quotations and lastly Customer Preview Make the status of the project editable directly through the kanban view. A new widget has been added to handle that properly. When editing the status through that means, a `project.update` will be created with the current date and the appropriate status. In addition to that a new status has been added (only on `project.task`, not `project.status`) namely `to_define` in order to differentiate new and running projects. Projects now start with the `to_define` status. The `project.project`'s rating stat button has been changed in the following ways: - The icon will now change in function of the satisfaction percentage, smile above 66%, meh between 33% and 66% and frown below 33%. - The color will also change depending on the rate, smile is green, meh is orange and frown is red. - The ratings will now be in function of the last 30 days instead of all time and the action will also filter on those 30 days. - Change the action name from 'Rating' to 'Ratings'. `project.project` ticket stat button: - Will now open the form view when there is only one record. - Added the activity view. - Disable the creation of new records. - Rename the action to 'Tickets'. Task ID: 2611006
The CRM pipeline analysis report now has clearer and more consistent search filters and grouping options. This makes it easier for sales teams to find, compare, and analyze pipeline data across community and enterprise editions.
Original PR description
PURPOSE
Improve the pipeline analysis search for a better usability.
SPECIFICATIONS
The goal of this commit is to improve the pipeline analysis search
view for a better usability, so the main changes going to be done
in this commit is reordering,renaming,removing and adding some
filters in the pipeline analysis report search view.
As we need to display same filters and groupby in both community and
enterprise pipeline report search view, we have removed the search
view `crm_opportunity_view_search` from enterprise so that we can use
the community view there and both becomes the same view.
So in this commit we have also added some filters and groupby to
community version(`crm.crm_opportunity_report_view_search`) which was
existed in enterprise search view (`crm_enterprise.crm_opportunity_view_search`)
so that we dont miss any filters used in enterprise.
LINKS
PR #71796
Task 2343223Searches that exclude matching linked records now avoid an unnecessary database lookup. This improves performance for users working with filters on related fields, especially on larger datasets.
Original PR description
[IMP] base: improve search on many2one with string values and negative operators
Currently, the domain expression on a many2one field with
negative operator + string values leads to a extra SQL request on the
target model of the many2one which is not optimal and lead to
performance degradation.
Example:
--------
With a simple model A with a one2many (`b_id`) targeting model B (with
a field `b_name` and `_rec_name = b_name`):
The `A.search([('b_id', 'not like', 'OneName')])` will
generate two SQL requests:
- A _name_search on model B and returning ids who match
`('b_name', 'not like', 'OneName')`.
- A other on the model A with the application of the result
of the first one `('b_id', 'in', <returning ids> + [False])`.
Solution:
---------
Avoid the extra SQL request (the first one) and use subquery instead.
We do it by translate the `('b_id', 'in', <returning ids> + [False])`
expression into ['|', ('b_id', 'in', _subquery), ('b_id', '=', False)]
task-2671476Project and field service users get a smoother experience with clearer project status updates, better stat buttons, improved portal task navigation, and more useful reporting views. The changes reduce unnecessary record creation, improve visibility into ratings, tickets, sales orders, hours, and milestones, and make common project information easier to manage.
Original PR description
* = helpdesk_fsm, helpdesk_timesheet, industry_fsm, industry_fsm_report, industry_fsm_sale, project_enterprise, project_forecast Smaller changes: - Projects created on the fly (through `name_create`)…
* = helpdesk_fsm, helpdesk_timesheet, industry_fsm, industry_fsm_report,
industry_fsm_sale, project_enterprise, project_forecast
Smaller changes:
- Projects created on the fly (through `name_create`) will now come with a
default `new` stage in order for them to not be empty.
- Removed task auto assign upon creation besides in FSM's 'My tasks' menu.
- Allow the reordering of projects without needing to group by
anything.
- Make `project.task`.`description` and `project.tags`.`name`
translatable.
- Disable the creation of records in the view when clicking on `Tasks
in recurrence` stat button.
- Track the planned date of the task in the chatter
- Disable the creation of records in the view when clicking on
'invoices' stat button and add the kanban view to that action.
- Make milestones completely available to regular project users.
- Remove the 'Documents' button in the project's kanban settings menu.
- Add kanban, pivot and graph views to the 'Hours Recorded' stat button
on projects
- Add the calendar view on the 'Hours Forecast' stat button on projects
- The 'Sales Orders' stat button on the `project.project`'s form view
will now display the amount of sales order linked to the whole
project. So the one linked to the project itself if it exists + all
the tasks. It will also open them, form view if 1 else list view.
- Fix a typo in the settings 'projets' => 'projects'
- The analytic account of the project will now be assigned to the
sales order when a task is created through the 'Create a task in an
existing project' option.
Changed the portal task view to include a sidebar similar to sales
orders, with a simple menu leading to different parts of the screen.
Changed the `project.task` 'rating' stat button:
- The icon will now represent the latest review.
- The action will directly lead to the record's form view if there is
only 1 rating.
- Make some fields readonly in the form view.
- Display the % of satisfaction instead of the number of ratings.
Reorder all stat buttons on the `project.task` form view in this order:
- Products, Worksheet, Sales Order(s), Invoices, Ratings, Hours
Forecast, Parent Task, Tasks in recurrence, Tickets, Quotations and
lastly Customer Preview
Make the status of the project editable directly through the kanban
view. A new widget has been added to handle that properly. When editing
the status through that means, a `project.update` will be created with
the current date and the appropriate status. In addition to that a new
status has been added (only on `project.task`, not `project.status`)
namely `to_define` in order to differentiate new and running projects.
Projects now start with the `to_define` status.
The `project.project`'s rating stat button has been changed in the
following ways:
- The icon will now change in function of the satisfaction percentage,
smile above 66%, meh between 33% and 66% and frown below 33%.
- The color will also change depending on the rate, smile is green, meh
is orange and frown is red.
- The ratings will now be in function of the last 30 days instead of
all time and the action will also filter on those 30 days.
- Change the action name from 'Rating' to 'Ratings'.
`project.project` ticket stat button:
- Will now open the form view when there is only one record.
- Added the activity view.
- Disable the creation of new records.
- Rename the action to 'Tickets'.
Task ID: 2611006Payroll batches no longer include a credit note option because corrections should be handled on each individual payslip. This reduces confusion and helps payroll teams manage adjustments at the right level of detail.
Original PR description
Purpose ======= This is not useful, this should be done payslip by payslip. TaskID: 2679674
CRM reporting dashboards now show related performance indicators in a clearer order and include recurring revenue metrics only for users who should see them. The CRM report search experience is also aligned with the standard Odoo version, making reporting more consistent across editions.
Original PR description
PURPOSE Improve the CRM reporting views. SPECIFICATIONS 0. Support "groups" attribute for dashboard view Add support of "groups" attribute for both aggregates and formulas. This is going to be necessary to hide recurring revenue fields in the crm app. 1. Harmonize search view with community This commit delete the search view `crm_opportunity_view_search` so that it matches with community version(`crm.crm_opportunity_report_view_search`). 2. Improve / rearrange KPIs on dashboard views Right now, on the dashboard view of leads, the KPIs are not in optimum order. This commit improves the behaviour by putting the related KPIs together (based on whether the leads are activated or not) and thus improves the reporting. See underlying commits for details. LINKS Community PR odoo/odoo#71796 PR #18797 Task 2343223
The Belgian payroll accounting test module now installs demo data more efficiently by grouping setup actions. This reduces setup time from about 125 seconds to about 100 seconds, helping teams run tests and prepare environments faster.
Original PR description
This is reducing the installation time of the module (with demo data activated) from ~125s to ~100s.
Product reports now show the correct price for each product template when different pricelists are used. This prevents customers or staff from seeing the same price repeated incorrectly across products, improving pricing accuracy in reports.
Original PR description
Description of the issue/feature this PR addresses: - Create a report to show price on each template --> Issue: The price is the same -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures sales, purchase, and accounting screens use the correct country-specific VAT when a company or transaction involves a foreign VAT fiscal position. It prevents incorrect tax options and wrong VAT details from appearing on orders and PDF documents, reducing invoicing and compliance errors.
Original PR description
[FIX] account: fiscal positions: filter tax country properly in view In case the address of the company is in a different country as its fiscal country, the taxes available as "source tax" on the fiscal position lines were not the right ones (the country of the address was used to fetch them). [FIX] purchase, sale: filter taxes properly when using a foreign VAT fiscal position Before, when a foreign VAT fiscal position was used on a purchase order or sale order, no filtering was applied on the available taxes. We now make their behavior consistent with the invoices'. [FIX] purchase, sale: display foreign VAT properly on pdf When printing a sale order or a purchase order using a foreign VAT fiscal position, the domestic VAT was always used on the pdf report instead of the foreign one.
This fixes the test setup for Peru electronic invoicing so it uses the correct VAT code. It helps ensure automated checks reflect valid local tax data and reduces the risk of false test failures.
In the website builder, when pasting a youtube url, we can transform it to an iframe in the editor through the Powerbox. Adding the iframe did not remove the text in the website builder. Now it properly remove the text in note and the website builder. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78375
Original PR description
In the website builder, when pasting a youtube url, we can transform it to an iframe in the editor through the Powerbox. Adding the iframe did not remove the text in the website builder. Now it properly remove the text in note and the website builder. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78375
Before this commit, the editor hint were not properly removed because the queryselector was made on the wrong document. Task-2678410 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79089
Original PR description
Before this commit, the editor hint were not properly removed because the queryselector was made on the wrong document. Task-2678410 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79089
When starting the editor in a web page, if there is no content, the oe_structure is not editable. Adding snippet at that moment will trigger `idSet` on the node with isUnbreakable returning `false` for the node that is unbreakable because of the check `!node.isContentEditable` in `isUnbreakable`. When setting the ouid for the first time with `idSet`, `getOuid` is called with `optimize` to `true`. So all the ancestor of a node that should be unbreakable will have the wrong ouid. Perfo
Original PR description
When starting the editor in a web page, if there is no content, the oe_structure is not editable. Adding snippet at that moment will trigger `idSet` on the node with isUnbreakable returning `false` for the node that is unbreakable because of the check `!node.isContentEditable` in `isUnbreakable`. When setting the ouid for the first time with `idSet`, `getOuid` is called with `optimize` to `true`. So all the ancestor of a node that should be unbreakable will have the wrong ouid. Performing any command to a node with a wrong ouid is suceptible to wrongly be reverted. By removing `!node.isContentEditable`, the node will have the proper ouid in case an ancestor is not editable. task-2633368 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#78897
### Latam Task 295 - Add a generic common module for tests in l10n_ar and related modules (l10n_ar_reports, l10n_ar_edi and l10n_ar_website_sale) - Move part of the initialization, helpers, and generic unit test from l10n_ar_edi to l10n_ar - Create all data used in the test on the fly, replicating what we have already in demo data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78477 Forward-Port-Of: odoo/odoo#75223
Original PR description
### Latam Task 295 - Add a generic common module for tests in l10n_ar and related modules (l10n_ar_reports, l10n_ar_edi and l10n_ar_website_sale) - Move part of the initialization, helpers, and generic unit test from l10n_ar_edi to l10n_ar - Create all data used in the test on the fly, replicating what we have already in demo data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78477 Forward-Port-Of: odoo/odoo#75223
`s_map` snippet is calling maps.google.com which might be the reason this tour experience some race condition when trying to drag and drop the `s_newsletter_subscribe_form` (which happen after the `s_map` snippet was dropped). When the race condition happen, we can see on the screenshot that the snippet was drag & dropped into the footer instead of the `s_text_image` inside the `#wrap` as it should be (see comment on first step of the test). The reason the snippet is not dropped where i
Original PR description
`s_map` snippet is calling maps.google.com which might be the reason this tour experience some race condition when trying to drag and drop the `s_newsletter_subscribe_form` (which happen after the…
`s_map` snippet is calling maps.google.com which might be the reason this tour experience some race condition when trying to drag and drop the `s_newsletter_subscribe_form` (which happen after the `s_map` snippet was dropped). When the race condition happen, we can see on the screenshot that the snippet was drag & dropped into the footer instead of the `s_text_image` inside the `#wrap` as it should be (see comment on first step of the test). The reason the snippet is not dropped where it should be is because the `s_map` was not removed as it should have been (seeing the screenshot), so the page was scrolled and the footer became the first available and visible `o_editable`. The `s_map` snippet is probably still in the DOM (despite a step is in charge of removing it) because it is recreated after the google maps server reply, which sometimes is probably taking an unexpected long time. Anyway, external services should never be called during tests, removing the snippet from the tour is an "easy" first step to try to fix the race condition. Forward-Port-Of: odoo/odoo#79102
This commit fixes the 'You need to supply a Lot/Serial Number...' message when validating a receipt with backorder for subcontracted tracked products. task: 2604664 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#79107 Forward-Port-Of: odoo/odoo#78062
Original PR description
This commit fixes the 'You need to supply a Lot/Serial Number...' message when validating a receipt with backorder for subcontracted tracked products. task: 2604664 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#79107 Forward-Port-Of: odoo/odoo#78062
Steps to reproduce: * Create PO * Confirm Receipt Date * Cancel PO * Draft and Confirm again Current behavior: * Button for Confirm Receipt Date is not visible Expected behavior: * Button for Confirm Receipt Date should be visible This is happening as we are not resetting the value of `mail_reminder_confirmed` on cancelling PO. With this commit, we reset value of `mail_reminder_confirmed` so use can Confirm Receipt Date again. Description of the issue/feature this
Original PR description
Steps to reproduce: * Create PO * Confirm Receipt Date * Cancel PO * Draft and Confirm again Current behavior: * Button for Confirm Receipt Date is not visible Expected behavior: * Button for Confirm Receipt Date should be visible This is happening as we are not resetting the value of `mail_reminder_confirmed` on cancelling PO. With this commit, we reset value of `mail_reminder_confirmed` so use can Confirm Receipt Date again. 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#59674
This reverts commit 2e58d23e760313dbf58ce6a90f26b7160db460d8. Actually the fleet officers want to be notified. The correct way to handle the original issue is to ping the employees via their documents, instead of on the fleet.vehicle, to avoid setting them as followers of the car. 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.
Original PR description
This reverts commit 2e58d23e760313dbf58ce6a90f26b7160db460d8. Actually the fleet officers want to be notified. The correct way to handle the original issue is to ping the employees via their documents, instead of on the fleet.vehicle, to avoid setting them as followers of the car. 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#78695
Issue: When returning a product sold that is only made of kits and validating the return, the delivered quantities of the sales order was set back to the full amount delivered Steps to reproduce : 1) Install MRP and Sales 2) Create a BoM Kit for a new product [Nested Kit] that has one or more consumable or storable product as component 3) Create a BoM Kit for a new product [Main Kit] that has [Nested Kit] as component 4) Create a SO for [Main Kit], confirm, validate de
Original PR description
Issue: When returning a product sold that is only made of kits and validating the return, the delivered quantities of the sales order was set back to the full amount delivered Steps to reproduce : 1)…
Issue: When returning a product sold that is only made of kits and
validating the return, the delivered quantities of the sales order was
set back to the full amount delivered
Steps to reproduce :
1) Install MRP and Sales
2) Create a BoM Kit for a new product [Nested Kit] that has one or
more consumable or storable product as component
3) Create a BoM Kit for a new product [Main Kit] that has
[Nested Kit] as component
4) Create a SO for [Main Kit], confirm, validate delivery
5) Check SO, 1 product is delivered (correct)
6) Go back to the Delivery, create a return for the delivery
(don't validate)
7) Check SO, 0 product is delivered (correct)
8) Now validate the return for the delivery
-> Check SO, 1 product is delivered (bug)
Why is that a bug:
Since the Main Kit was returned, the delivered should be 0 and not
the full amount initially delivered. It was set back to 1 because we
didn't look at the type of picking, when computing the quantity
delivered, the fall back considered that if all the moves were done,
everything was delivered, but it is the opposite when returning
opw-2542337
Forward-Port-Of: odoo/odoo#78838
Forward-Port-Of: odoo/odoo#75256Before this commit, the router didn't considered as equal an integer value given as an integer or as a string (e.g. "1" or 1), whereas form the url point of view, it's exactly the same, and the information is lost anyway. As a consequence, pushing something like { id: "1" } in the url that already contained id=1 created a new entry in the history, which isn't what we want as the url is the same. This commit fixes the issue by converting string values into numbers when it is possible.
Original PR description
Before this commit, the router didn't considered as equal an
integer value given as an integer or as a string (e.g. "1" or 1),
whereas form the url point of view, it's exactly the same, and the
information is lost anyway.
As a consequence, pushing something like { id: "1" } in the url
that already contained id=1 created a new entry in the history,
which isn't what we want as the url is the same.
This commit fixes the issue by converting string values into
numbers when it is possible.
This commit also changes the way the action service pushes the id
and active_id in the url, as there's no need to pass string values
anymore (this was the case in the early days of the wowl branch).
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#79029Avoids the ambiguity of the department_id column in hr_attendance_report.py by specifying the table in the SELECT clause. While upgrading to Odoo 15.0, if the database contains a module that adds the column department_id to the table hr_attendance_overtime, the following error occurs: ``` Traceback (most recent call last): File "/home/odoo/src/odoo/15.0/odoo/service/server.py", line 1246, in preload_registries registry = Registry.new(dbname, update_module=update_module) File
Original PR description
Avoids the ambiguity of the department_id column in hr_attendance_report.py by specifying the table in the SELECT clause. While upgrading to Odoo 15.0, if the database contains a module that adds the…
Avoids the ambiguity of the department_id column in
hr_attendance_report.py by specifying the table in the SELECT clause.
While upgrading to Odoo 15.0, if the database contains
a module that adds the column department_id to
the table hr_attendance_overtime, the following error occurs:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/service/server.py", line 1246, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/15.0/odoo/modules/registry.py", line 87, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/15.0/odoo/modules/loading.py", line 472, in load_modules
force, status, report, loaded_modules, update_module, models_to_check)
File "/home/odoo/src/odoo/15.0/odoo/modules/loading.py", line 365, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/home/odoo/src/odoo/15.0/odoo/modules/loading.py", line 199, in load_module_graph
registry.init_models(cr, model_names, {'module': package.name}, new_install)
File "/home/odoo/src/odoo/15.0/odoo/modules/registry.py", line 425, in init_models
model.init()
File "/home/odoo/src/odoo/15.0/addons/hr_attendance/report/hr_attendance_report.py", line 50, in init
""" % (self._table))
File "<decorator-gen-3>", line 2, in execute
File "/home/odoo/src/odoo/15.0/odoo/sql_db.py", line 89, in check
return f(self, *args, **kwargs)
File "/home/odoo/src/odoo/15.0/odoo/sql_db.py", line 310, in execute
res = self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "department_id" is ambiguous
LINE 6: department_id,
^
```
upg-42212
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#78524Since commit `37eb0dfbb54` it was no longer possible to create Expense Products. The field `detailed_type` was not present in the view hence it didn't get its default value of 'service'. TaskID: 2678961 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#79115
Original PR description
Since commit `37eb0dfbb54` it was no longer possible to create Expense Products. The field `detailed_type` was not present in the view hence it didn't get its default value of 'service'. TaskID: 2678961 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#79115
Under account.document_tax_totals template the subtotal and total were using the float amounts for printing. There was the formatted currency returned from _compute_tax_totals_json but not printed. This commit uses the formatted_amount and formatted_amount_total keys to display the amount with currency on PDF and portal view. closes #77996 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79064
Original PR description
Under account.document_tax_totals template the subtotal and total were using the float amounts for printing. There was the formatted currency returned from _compute_tax_totals_json but not printed. This commit uses the formatted_amount and formatted_amount_total keys to display the amount with currency on PDF and portal view. closes #77996 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79064
Since the addition of <a> tag with `href='#'` added in https://github.com/odoo/enterprise/pull/16579 the default behaviour of the click was to go back to `rootUrl/web#` which was closing the documents app and therefore the PDF splitter. This commit fixes this issue. opw-2668807 Forward-Port-Of: odoo/enterprise#21967
Original PR description
Since the addition of <a> tag with `href='#'` added in https://github.com/odoo/enterprise/pull/16579 the default behaviour of the click was to go back to `rootUrl/web#` which was closing the documents app and therefore the PDF splitter. This commit fixes this issue. opw-2668807 Forward-Port-Of: odoo/enterprise#21967
**The SEPA direct debit mandate report always uses the company header of the first company in the DB rather than that of the mandate beneficiary. ** Impacted versions: 13.0, 14.0, 15.0 Steps to reproduce: 1. Create a DB and install the `account_sepa_direct_debit` module. Set up the DB with at least 2 companies and configure the document layout for the companies to display their address (so that you can easily spot the difference) 2. Select a company other than the company with index 1
Original PR description
**The SEPA direct debit mandate report always uses the company header of the first company in the DB rather than that of the mandate beneficiary. ** Impacted versions: 13.0, 14.0, 15.0 Steps to…
**The SEPA direct debit mandate report always uses the company header of the first company in the DB rather than that of the mandate beneficiary. **
Impacted versions: 13.0, 14.0, 15.0
Steps to reproduce:
1. Create a DB and install the `account_sepa_direct_debit` module. Set up the DB with at least 2 companies and configure the document layout for the companies to display their address (so that you can easily spot the difference)
2. Select a company other than the company with index 1 in res_company.
3. Go to Accounting/SEPA Direct Debit Mandates/Create
4. Select any client and enter IBAN details - if you need dummy data, these are from Amy-Caroline's tutorial:
BE81 8979 6289 4224
ING – BBRUBEBB
5. Select a journal, e.g. 'Bank' and enter IBAN details - here's some more dummy data from the tutorial:
BE44 7359 2299 9545
BNP Paribas - GEBABEBB
6. Click 'Save'
7. Click 'Print'
Current behavior:
- The header does not correspond to the company issuing the mandate, but rather to the first company in the DB.
Expected behavior:
- The header should be that of the company issuing the mandate.
Code analysis:
- The code responsible for setting the correct header and document format is at [empty_mandate_report.xml:24](https://github.com/odoo/enterprise/blob/master/account_sepa_direct_debit/report/empty_mandate_report.xml#L24) which calls the `external_layout` template defined at [report_templates.xml:471](https://github.com/odoo/odoo/blob/master/addons/web/views/report_templates.xml#L471).
- The `external_layout` template expects a `o` or `doc` object to exist, corresponding to the object for which the report will be generated. As can be seen from other reports, e.g. [report_invoice.xml:252](https://github.com/odoo/odoo/blob/master/addons/account/views/report_invoice.xml#L252), the `o` object is usually set, which enables the `external_layout` template to retrieve the correct company at [report_templates.xml:480](https://github.com/odoo/odoo/blob/master/addons/web/views/report_templates.xml#L480).
- However, in [empty_mandate_report.xml:17](https://github.com/odoo/enterprise/blob/master/account_sepa_direct_debit/report/empty_mandate_report.xml#L17) the object for which the report is to be generated is named not `o` or `doc` but rather `mandate`.
- As a result, [report_templates.xml:480](https://github.com/odoo/odoo/blob/master/addons/web/views/report_templates.xml#L480), which should have retrieved the correct company, does not execute; and instead [report_templates.xml:483](https://github.com/odoo/odoo/blob/master/addons/web/views/report_templates.xml#L483) executes, which simply selects the database's first company.
Solution:
- Rename `mandate` to `o` in [empty_mandate_report.xml:17](https://github.com/odoo/enterprise/blob/master/account_sepa_direct_debit/report/empty_mandate_report.xml#L17), propagating the change.
Fixes Support Ticket no. 2663561
Merci à @oco-odoo pour ton intérêt pour ce fix :smile:
Forward-Port-Of: odoo/enterprise#21899This commit is the counterpart of [1], where we no longer push the state in the url if it hasn't changed. In the updated test, we relied on that faulty behavior. [1] https://github.com/odoo/odoo/pull/79029 Forward-Port-Of: odoo/enterprise#21929
Original PR description
This commit is the counterpart of [1], where we no longer push the state in the url if it hasn't changed. In the updated test, we relied on that faulty behavior. [1] https://github.com/odoo/odoo/pull/79029 Forward-Port-Of: odoo/enterprise#21929
Autofill a header cell such that the autofilled cell will become a "Total" formula: the tooltip is an empty square. Task 2627495 Forward-Port-Of: odoo/enterprise#21927 Forward-Port-Of: odoo/enterprise#20944
Original PR description
Autofill a header cell such that the autofilled cell will become a "Total" formula: the tooltip is an empty square. Task 2627495 Forward-Port-Of: odoo/enterprise#21927 Forward-Port-Of: odoo/enterprise#20944
### Latam Task 295 Adapt l10n_ar_edi tests to account tests, inheriting from the class defined in l10n_ar where we are creating the data on the fly. --- Forward-Port-Of: odoo/enterprise#21734 Forward-Port-Of: odoo/enterprise#20298
Original PR description
### Latam Task 295 Adapt l10n_ar_edi tests to account tests, inheriting from the class defined in l10n_ar where we are creating the data on the fly. --- Forward-Port-Of: odoo/enterprise#21734 Forward-Port-Of: odoo/enterprise#20298