Thursday, October 22, 2020
33 changes · master
Security fixes and vulnerability patches
This update raises a key web server library to a newer version to address known vulnerabilities and improve platform reliability. It also includes minor documentation and translation-related file updates, with no expected change to day-to-day user workflows.
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
Enhancements to existing features
This change improves how Odoo calculates quantities for product kits by processing them in batches. Businesses with manufacturing or stock operations involving kits should see faster quantity updates and smoother performance, especially with larger product catalogs.
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
Resolved issues and error corrections
This update refreshes the website editor component and adjusts automated checks so the editor continues to work reliably in embedded editing views. It also fixes small usability issues around template overflow, mobile selection boundaries, and editing links.
Original PR description
- iframe editor Qunit test
Miscellaneous changes
- Create companies A & B - Create a Dropship route for B - Create a product P with route 'Dropship' - Set the website under company A - As a portal user, buy the product P on the website - Do the payment The SO is confirmed but the Dropship route for B is used despite the fact that the website is under company A. This happens because `_search_rule` is called as superuser: therefore, routes from all companies are retrieved. To prevent this, we add the company in the domain. opw
Original PR description
- Create companies A & B - Create a Dropship route for B - Create a product P with route 'Dropship' - Set the website under company A - As a portal user, buy the product P on the website - Do the payment The SO is confirmed but the Dropship route for B is used despite the fact that the website is under company A. This happens because `_search_rule` is called as superuser: therefore, routes from all companies are retrieved. To prevent this, we add the company in the domain. opw-2349094 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#60475 Forward-Port-Of: odoo/odoo#59444
The web interface now better supports action menus on mobile devices, including more reliable dropdown placement and a mobile-friendly export data screen. This makes key list actions easier to access and use on phones and tablets.
Original PR description
This merge sets up the requirements to enable the action menu on mobile device. In a nutshell : * allow to simulate touch-screen device in the QUnit tests * fix the DropdownMenu OWL component to not open out of the viewport * add the required hooks to be used on enterprise * improve the UX of the export modal on mobile Related PR: https://github.com/odoo/enterprise/pull/11960 Task ID: 1879566
The chatter area now keeps only the message composer fixed while the rest of the conversation can scroll normally. This improves usability by keeping message entry accessible without making the full chatter panel feel stuck on screen.
Original PR description
task-2282325
Website footer templates that include a logo can now show the company or website name as text instead of only using an image. This gives businesses more flexibility in branding and also ensures header text uses the actual website name rather than a generic placeholder.
Original PR description
Applies to footer templates that contain the logo ('Centered',
'Minimalist' and 'Contact')
Before this commit the logo in footer is always displayed as an image.
After this commit the logo in footer can also be displayed as a text.
task-2368697
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-prWebsite editors can now set background styles on individual columns within a row. This gives teams more layout flexibility and helps create more visually distinct page sections without custom development.
Original PR description
Current behavior before PR: Currently the columns of a row (.row > div) do not have the option to change the background. Desired behavior after PR is merged: The columns of a row (.row > div) have the option. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mobile users can now access Print and Action menus in list and form views, including customer-specific actions configured in their database. The mobile selection experience was redesigned to save screen space, and print menus now close automatically after use on mobile.
Original PR description
This merge enables ControlPanel's ActionMenus ('Print' and 'Action') in
List/Form view on mobile.
The main purpose of enabling it is to give users access to the basic
actions but also the custom actions implemented in the client's
database.
To do so it uses common Material patterns by placing the selection banner
in place of the ControlPanel's bottom section when in "selection mode".
Also, the rows' checkboxes are replaced by a highlight on the selected rows
to save as much space as possible on small screens.
Note: we had to disable the "read-only editable list" as interacting
with selection AND keeping this feature was heavily error-prone for the
user.
Reference:
https://material.io/design/interaction/selection.html
Task ID: 1879566The EC Sales List report has been improved by bringing country-specific reporting requirements into the general report. This helps companies produce the right sales list information for their local compliance needs with a more consistent reporting experience.
Original PR description
…eneric EC Sales List report Addapt EC Sales List report to meet current company country requirements Task: 2217469
A tax line could have something in the `tax_ids` field. Then, these condition needs to be inversed in order to not handle them as base lines. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60382 Forward-Port-Of: odoo/odoo#60337
Original PR description
A tax line could have something in the `tax_ids` field. Then, these condition needs to be inversed in order to not handle them as base lines. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60382 Forward-Port-Of: odoo/odoo#60337
Before this commit, Field "No of Views (visits)" was editable on multi_edit mode. Field "No of Views (visits)" should be readonly for Obvious reason. 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#60483
Original PR description
Before this commit, Field "No of Views (visits)" was editable on multi_edit mode. Field "No of Views (visits)" should be readonly for Obvious reason. 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#60483
Before this commit, Going to Website --> Configurations --> Apps was displaying Modules related to Website only but the default focus on searchpanel was on "All". (https://tinyurl.com/y5tw5uob) Now, The default focus of searchpanel is on Website Category. (https://tinyurl.com/y6984hl7) 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
Before this commit, Going to Website --> Configurations --> Apps was displaying Modules related to Website only but the default focus on searchpanel was on "All". (https://tinyurl.com/y5tw5uob) Now, The default focus of searchpanel is on Website Category. (https://tinyurl.com/y6984hl7) 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#60479
The fix c710c3a35a3f466ebadc5748c70784bc063a7eb2 has been forgotten while applying https://github.com/odoo/odoo/pull/43768 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60282
Original PR description
The fix c710c3a35a3f466ebadc5748c70784bc063a7eb2 has been forgotten while applying https://github.com/odoo/odoo/pull/43768 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60282
This commit fixes a small issue with the modal displayed when the user wants to manage his subscription to a course. When pressing the "Save" button, if no modification was made, the modal would not close and nothing would happen (which seems strange on a user POV). Now the modal correctly destroys itself and closes. Task 2363028 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have sig
Original PR description
This commit fixes a small issue with the modal displayed when the user wants to manage his subscription to a course. When pressing the "Save" button, if no modification was made, the modal would not close and nothing would happen (which seems strange on a user POV). Now the modal correctly destroys itself and closes. Task 2363028 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#60412
When the overlay covers a snippet, if that snippet is at the top of the page, the options at the top of the overlay are hidden. A system was made to make them change position in that case but this was broken by [1], leaving the toggling of a class for that case but without its related scss. This commit restores that scss and also improves the detection of that problematic case. [1]: https://github.com/odoo/odoo/commit/4f27e52cabb77b8b1a9637a11185ddf882adc9af Forward-Port-Of: odoo/odo
Original PR description
When the overlay covers a snippet, if that snippet is at the top of the page, the options at the top of the overlay are hidden. A system was made to make them change position in that case but this was broken by [1], leaving the toggling of a class for that case but without its related scss. This commit restores that scss and also improves the detection of that problematic case. [1]: https://github.com/odoo/odoo/commit/4f27e52cabb77b8b1a9637a11185ddf882adc9af Forward-Port-Of: odoo/odoo#60437 Forward-Port-Of: odoo/odoo#60427
Before this commit, when sub widget replaced its el, the ComponentAdapter parent kept the previous el. This caused some issues as in the ActivityRecordAdapter which lost its event listeners when re-rendered. This commit forces the ComponentAdapter to keep the new sub widget el after being patched. task id: 2360021 Forward-Port-Of: odoo/odoo#60506
Original PR description
Before this commit, when sub widget replaced its el, the ComponentAdapter parent kept the previous el. This caused some issues as in the ActivityRecordAdapter which lost its event listeners when re-rendered. This commit forces the ComponentAdapter to keep the new sub widget el after being patched. task id: 2360021 Forward-Port-Of: odoo/odoo#60506
### Task 392 Description of the issue/feature this PR addresses: Add missing translations from task 366 in l10n_ar project. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#59030
Original PR description
### Task 392 Description of the issue/feature this PR addresses: Add missing translations from task 366 in l10n_ar project. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#59030
When the overlay covers a snippet, if that snippet is at the top of the page, the options at the top of the overlay are hidden. A system was made to make them change position in that case but this was broken by [1], leaving the toggling of a class for that case but without its related scss. This commit restores that scss and also improves the detection of that problematic case. [1]: https://github.com/odoo/odoo/commit/4f27e52cabb77b8b1a9637a11185ddf882adc9af Forward-Port-Of: odoo/odo
Original PR description
When the overlay covers a snippet, if that snippet is at the top of the page, the options at the top of the overlay are hidden. A system was made to make them change position in that case but this was broken by [1], leaving the toggling of a class for that case but without its related scss. This commit restores that scss and also improves the detection of that problematic case. [1]: https://github.com/odoo/odoo/commit/4f27e52cabb77b8b1a9637a11185ddf882adc9af Forward-Port-Of: odoo/odoo#60464 Forward-Port-Of: odoo/odoo#60427
Add a padding on list-inline-item in the language selector. Because before this commit, there was no space between lines if the list was to be displayed on multiple lines. task-2312878 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#59581
Original PR description
Add a padding on list-inline-item in the language selector. Because before this commit, there was no space between lines if the list was to be displayed on multiple lines. task-2312878 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#59581
The alignment of quantity and product name was off when the product name was split into multiple lines. opw-2360424 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60516
Original PR description
The alignment of quantity and product name was off when the product name was split into multiple lines. opw-2360424 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#60516
task-2359991 Forward-Port-Of: odoo/odoo#60535
Original PR description
task-2359991 Forward-Port-Of: odoo/odoo#60535
…ted execution Cron hold a lastcall field and context key allowing to an accessible range of processable records, based on its last execution. This value is updated when cron runs automatically. Manual call currently does not update it although it makes sense. Lastcall context key is also updated. It is used notably in calendar. Otherwise only mails linked to "today" are taken into account, leading to reminder issues. Task ID-2331999 Forward-Port-Of: odoo/odoo#60537 Forward-Port-O
Original PR description
…ted execution Cron hold a lastcall field and context key allowing to an accessible range of processable records, based on its last execution. This value is updated when cron runs automatically. Manual call currently does not update it although it makes sense. Lastcall context key is also updated. It is used notably in calendar. Otherwise only mails linked to "today" are taken into account, leading to reminder issues. Task ID-2331999 Forward-Port-Of: odoo/odoo#60537 Forward-Port-Of: odoo/odoo#60345
Before this commit, archived and deleted partners had not their im_status being updated automatically. There were some issues with this, notably: - odoobot 'bot' status was not displayed in chatter - im_status of partners becoming archived were not updated. This commit fixes both issues. task-2329591 Forward-Port-Of: odoo/odoo#60398
Original PR description
Before this commit, archived and deleted partners had not their im_status being updated automatically. There were some issues with this, notably: - odoobot 'bot' status was not displayed in chatter - im_status of partners becoming archived were not updated. This commit fixes both issues. task-2329591 Forward-Port-Of: odoo/odoo#60398
Skip the computation of the field `l10n_latam_document_type_id` at the module installation. The case has been detected during an upgrade from Odoo 12.0 to Odoo 13.0, but the case could really well happen outside the context of an upgrade, for instance when you create a new subsidiary in Chile or Argentina while you already have a lot of accounting entries in your other subsidiaries (e.g. Odoo S.A. opens a new office in Chile and has to install `l10n_cl`) Without this, at the module ins
Original PR description
Skip the computation of the field `l10n_latam_document_type_id` at the module installation. The case has been detected during an upgrade from Odoo 12.0 to Odoo 13.0, but the case could really well…
Skip the computation of the field `l10n_latam_document_type_id` at the module installation.
The case has been detected during an upgrade from Odoo 12.0 to Odoo 13.0,
but the case could really well happen outside the context of an upgrade,
for instance when you create a new subsidiary in Chile or Argentina
while you already have a lot of accounting entries in your other subsidiaries
(e.g. Odoo S.A. opens a new office in Chile and has to install `l10n_cl`)
Without this, at the module installation,
it would call `_compute_l10n_latam_document_type` on all existing records
which can take quite a while if you already have a lot of moves. It can even fail with a MemoryError.
In addition, it sets `_compute_l10n_latam_document_type = False` on all records
because this field depends on the many2many `l10n_latam_available_document_type_ids`,
which relies on having records for the model `l10n_latam.document.type`
which only happens once the according localization module is loaded.
(e.g. `l10n_cl/data/l10n_latam.document.type.csv`)
The localization module is loaded afterwards, because the localization module depends on this module,
(e.g. `l10n_cl` depends on `l10n_latam_invoice_document`, and therefore `l10n_cl` is loaded after)
and therefore there are no records for the model `l10n_latam.document.type` at the time this fields
gets computed on installation. Hence, all records' `_compute_l10n_latam_document_type` are set to `False`.
In addition, multiple localization module depends on this module (e.g. `l10n_cl`, `l10n_ar`)
So, imagine `l10n_cl` gets installed first, and then `l10n_ar` is installed next,
if `l10n_latam_document_type_id` needed to be computed on install,
the install of `l10n_cl` would call the compute method,
because `l10n_latam_invoice_document` would be installed at the same time,
but then `l10n_ar` would miss it, because `l10n_latam_invoice_document` would already be installed.
Besides, this field is computed only for drafts invoices, as stated in the compute method:
`for rec in self.filtered(lambda x: x.state == 'draft'):`
So, if we want this field to be computed on install, it must be done only on draft invoices, and only once
the localization modules are loaded.
It should be done in a dedicated post init hook,
filtering correctly the invoices for which it must be computed.
Though I don't think this is needed.
In practical, it's very rare to already have invoices (draft, in addition)
for a Chilian or Argentian company (`res.company`) before installing `l10n_cl` or `l10n_ar`.
```
Traceback (most recent call last):
File "/src/odoo/13.0/odoo/service/server.py", line 1190, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/src/odoo/13.0/odoo/modules/registry.py", line 86, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/src/odoo/13.0/odoo/modules/loading.py", line 423, in load_modules
loaded_modules, update_module, models_to_check)
File "/src/odoo/13.0/odoo/modules/loading.py", line 315, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/src/odoo/13.0/odoo/modules/loading.py", line 202, in load_module_graph
registry.init_models(cr, model_names, {'module': package.name}, new_install)
File "/src/odoo/13.0/odoo/modules/registry.py", line 364, in init_models
env['base'].flush()
File "/src/odoo/13.0/odoo/models.py", line 5458, in flush
self.recompute()
File "/src/odoo/13.0/odoo/models.py", line 5875, in recompute
process(field)
File "/src/odoo/13.0/odoo/models.py", line 5859, in process
recs.mapped(field.name)
File "/src/odoo/13.0/odoo/models.py", line 5266, in mapped
recs = recs._mapped_func(operator.itemgetter(name))
File "/src/odoo/13.0/odoo/models.py", line 5225, in _mapped_func
vals = [func(rec) for rec in self]
File "/src/odoo/13.0/odoo/models.py", line 5225, in <listcomp>
vals = [func(rec) for rec in self]
File "/src/odoo/13.0/odoo/models.py", line 5690, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/src/odoo/13.0/odoo/fields.py", line 2329, in __get__
return super().__get__(records, owner)
File "/src/odoo/13.0/odoo/fields.py", line 995, in __get__
self.compute_value(recs)
File "/src/odoo/13.0/odoo/fields.py", line 1109, in compute_value
records._compute_field_value(self)
File "/src/odoo/13.0/odoo/models.py", line 3968, in _compute_field_value
field.compute(self)
File "/src/odoo/13.0/odoo/fields.py", line 579, in _compute_related
record[self.name] = self._process_related(value[self.related_field.name])
File "/src/odoo/13.0/odoo/models.py", line 5699, in __setitem__
return self._fields[key].__set__(self, value)
File "/src/odoo/13.0/odoo/fields.py", line 1070, in __set__
self.write(protected_records, value)
File "/src/odoo/13.0/odoo/fields.py", line 2564, in write
cache.update(records, self, [cache_value] * len(records))
File "/src/odoo/13.0/odoo/api.py", line 768, in update
field_cache.setdefault(record_id, {})[key] = value
MemoryError
```
Upgrade request 49495
Forward-Port-Of: odoo/odoo#60569
Forward-Port-Of: odoo/odoo#60544When you want to signal to a customer that the due date is coming soon, you may want to set a negative number of days in the followup level. This didn't work because we used the default minimum number to find the next followup level at 0. opw-[2350614](https://www.odoo.com/web#active_id=2350614&cids=1&id=2350614&model=project.task&menu_id=) opw-[2360899](https://www.odoo.com/web#active_id=2360899&cids=1&id=2360899&model=project.task&menu_id=) Forward-Port-Of: odoo/enterprise#14330 Forwar
Original PR description
When you want to signal to a customer that the due date is coming soon, you may want to set a negative number of days in the followup level. This didn't work because we used the default minimum number to find the next followup level at 0. opw-[2350614](https://www.odoo.com/web#active_id=2350614&cids=1&id=2350614&model=project.task&menu_id=) opw-[2360899](https://www.odoo.com/web#active_id=2360899&cids=1&id=2360899&model=project.task&menu_id=) Forward-Port-Of: odoo/enterprise#14330 Forward-Port-Of: odoo/enterprise#14280
Target project_id field so event watched is autocompleteselect that will consume the tip when a project is selected, and not just the click event on the element. opw-2352622 Forward-Port-Of: odoo/enterprise#14326
Original PR description
Target project_id field so event watched is autocompleteselect that will consume the tip when a project is selected, and not just the click event on the element. opw-2352622 Forward-Port-Of: odoo/enterprise#14326
This fix solves 2 encountered issues when a call is rejected. First of all, if you call someone which is already in an active call, the denied answer was not correctly interpreted on the "caller" side as the session was not cancelled. Now a message telling that the "callee" is not available is displayed and the session is cancelled. The second issue appears when the sip_ignore_incomming fields was activated. In this case, the call was always rejected. The problem is that the call may be
Original PR description
This fix solves 2 encountered issues when a call is rejected. First of all, if you call someone which is already in an active call, the denied answer was not correctly interpreted on the "caller" side as the session was not cancelled. Now a message telling that the "callee" is not available is displayed and the session is cancelled. The second issue appears when the sip_ignore_incomming fields was activated. In this case, the call was always rejected. The problem is that the call may be redirected elsewhere, on a desk phone for e.g.. The previous solution does not allows this case. see: https://tools.ietf.org/html/rfc3261#section-21.6.2 for status code Forward-Port-Of: odoo/enterprise#14309
Issue - Install "Subscription" - Create a subscriptionA with CustomerA and referenceX - Create a subscriptionB with CustomerB and referenceX and renewable - Renew subscriptionB The CustomerA will be linked to subscriptionB instead of the customerB Cause The domain condition was not correct because it only matched the order reference Solution Add partner check in addition to the order reference to the domain condition opw-2352620 Forward-Port-O
Original PR description
Issue
- Install "Subscription"
- Create a subscriptionA with CustomerA and referenceX
- Create a subscriptionB with CustomerB and referenceX and renewable
- Renew subscriptionB
The CustomerA will be linked to subscriptionB instead of the customerB
Cause
The domain condition was not correct because it only matched the order reference
Solution
Add partner check in addition to the order reference to the domain condition
opw-2352620
Forward-Port-Of: odoo/enterprise#14282Behavior prior to the fix: When shipping a package with a very small weight, the weight was rounded down to 0 oz, causing EasyPost to refuse the request. The rounding is always performed at 0.1 precision, because that is what EasyPost accepts, thus a package of less than 0.05oz would be rounded down to 0. Behavior after the fix: When computing the weight a bottom cap of 0.1oz was introduced. This will only affect shipments with very low weight. Note: An alternative would hav
Original PR description
Behavior prior to the fix: When shipping a package with a very small weight, the weight was rounded down to 0 oz, causing EasyPost to refuse the request. The rounding is always performed at 0.1 precision, because that is what EasyPost accepts, thus a package of less than 0.05oz would be rounded down to 0. Behavior after the fix: When computing the weight a bottom cap of 0.1oz was introduced. This will only affect shipments with very low weight. Note: An alternative would have been to use a rounding method of UP, which would be similar to what other carriers plugins (eg delivery_fedex) are using, but might adversedly affect shipments with weights very slightly above the 1oz mark (for example 1lb1.05oz would become 1lb1.1oz) opw-2362389 Forward-Port-Of: odoo/enterprise#14293
Behavior prior to the fix: If I, in the Brussels timezone, move or copy a task (on the planner) from 10/20/20 to 10/27/20, and it was originally scheduled at 08:00 CEST, the schedule will change to 07:00 CEST (still 06:00 GMT in both cases) Behavior after the fix: The system uses the web user's timezone (as identified by their browser) to perform the time adjustment calculation. The second occurence will thus be on 10/27 08:00 local time (CET) (so 07:00 GMT). NOTE: Another commit
Original PR description
Behavior prior to the fix: If I, in the Brussels timezone, move or copy a task (on the planner) from 10/20/20 to 10/27/20, and it was originally scheduled at 08:00 CEST, the schedule will change to 07:00 CEST (still 06:00 GMT in both cases) Behavior after the fix: The system uses the web user's timezone (as identified by their browser) to perform the time adjustment calculation. The second occurence will thus be on 10/27 08:00 local time (CET) (so 07:00 GMT). NOTE: Another commit will follow for opw-2349735 to implement the backend change necessary to the planning module for recurrency and copy period functions, as well as the performance issue identified on that ticket. opw-2349735 Forward-Port-Of: odoo/enterprise#14300 Forward-Port-Of: odoo/enterprise#13968
TLDR: obsolete line broke reconciliation workflow STEPS: * install accounting * create second bank journal * in accounting dashboard click "import statement" for the new journal * upload csv file and click import BEFORE: you are redirecting to reconciliation page with wrong context, e.g. breadcrumb and title have name of first bank: "Accounting Overview > Import a File > BANK (USD) AFTER: reconciliation works as expected EXPLANATION: * the line comes from #5797, which make
Original PR description
TLDR: obsolete line broke reconciliation workflow STEPS: * install accounting * create second bank journal * in accounting dashboard click "import statement" for the new journal * upload csv file and click import BEFORE: you are redirecting to reconciliation page with wrong context, e.g. breadcrumb and title have name of first bank: "Accounting Overview > Import a File > BANK (USD) AFTER: reconciliation works as expected EXPLANATION: * the line comes from #5797, which makes sense in Odoo 12, but then it was wrongly forward-ported to Odoo 13 in #5831 * for structure of message argument see * https://github.com/odoo/odoo/blame/836ff55dc9f473a61f0c50c15fb5468d75959a83/addons/base_import/models/base_import.py#L905-L944 * https://github.com/odoo/odoo/blob/71d8f32cb95007f8e66e6aaf1a680466f960417a/odoo/models.py#L889 --- opw-2366301 Forward-Port-Of: odoo/enterprise#14262
The category should be 'Accounting', not 'Account'. opw-2368021 Forward-Port-Of: odoo/enterprise#14312
Original PR description
The category should be 'Accounting', not 'Account'. opw-2368021 Forward-Port-Of: odoo/enterprise#14312