*: im_livechat, website_livechat, website_slides
In c989ff3, the odoo module system has been changed so that it now
errors out when modules are defined but have missing dependencies and
cannot run. Unfortunately, tours are defined in a single bundle,
`assets_tests`, and this bundle is used everywhere tours need to run,
but some of these tours depend on modules that only exist in the backend
and others on modules that only exist in the frontend. We don't want to
break up the `assets_tests` bundle as this creates a poor developer
experience, and so the solution that was chosen at the time is that when
the `assets_tests` bundle is defined, we ignore all module dependency
errors.
This causes a problem however, which is that if a module dependency is
missing in production code, the page will be broken by the module error
(which is expected) but if the `assets_tests` are present, which is the
case when running tours and tests, then it won't, meaning the tours will
happily pass despite the application being broken, which is
unacceptable.
This commit fixes this issue by replacing the assets_test bundle by a
new bundle (`__assets_tests_call__`) within which all module dependency
errors are ignored, which lets dependency errors that are hapenning in
other bundles (ie in production code) happen even during the tests.
Because of this, this commit also fixes the dependency errors that
already existed but were previously silent:
- for im_livechat and website_livechat, the code was refactored to use
the standard mechanism that we use elsewhere to add data directly in the
page: we store the data in __session_info__, and the module that exposes
that data is always present, instead of having a module that's defined
conditionally, which causes issues when non-conditional modules depend
on it.
- in web, the `report_assets_common` bundle was used alongside
`assets_common` but without `assets_frontend` or `assets_backend`.
Reports do not need any js and it appears that it already had what it
needed as far as css is concerned except for one fontawesome override.
Code was changed so that the js from the bundle is not included and it
reports no longer use `assets_common`, the js part of the bundle is no
longer used.
- in website_slides, the `slide_embed_assets` bundle is used alongside
`assets_common` without using `assets_frontend` or `assets_backend`
which is required for `assets_common` to function, the approach here was
to simply take the files from `assets_common` and remove the files that
were causing issues. This bundle should be trimmed at some point, as it
contains way too many things that it does not need.
The file colors.js was also moved to core, as it isn't graph specific
and was causing dependency issues with a field that was importing it.
Fields shouldn't depend on files in specific views' directory.
closesodoo/odoo#104794
Related: odoo/enterprise#33909
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When the price and the event are the same, nothing allows
ordering tickets in event_sale. Therefore, add a sequence
number and handle widget to the tickets (in data as well).
Also do it for ticket templates. Also, order the tickets
(on events and templates) by name before id.
Since event type tickets are not linked to any event, the
order does not include the event_id. However, event event
tickets are, and if they appear in the same list / reporting
someday, it makes sense to order them by event_id first.
In event_sale, we make sure the price is also in the order.
As the price is in the copied fields on the event when
using an event template, we add the price on the event
type tickets ordering to align with the event event tickets.
Add default value to sequence and sequence number to data
for event.type model. They were sequenced but demo data had
none, hence not really ordered.
We also add the id in the event.event _order value, otherwise
when ordering on the event (for instance ordering on event_id
for event.event.tickets), the order is random for events
having the same date_begin. We prevent this from happening.
Also make description optional hide on event types.
Task-2997391
closesodoo/odoo#101384
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
It is not possible to consume a component tracked by serial that comes
back from a scrap location
To reproduce the issue:
1. In Settings, enable "Multi Routes"
2. Create two storable products P_compo, P_finished
- P_compo is tracked by serial number
3. Update the on-hand qty of P_compo:
- 1 x P_compo with serial SN
4. Process a manufacturing order MO:
- Product: P_finished
- Compo: 1 x P_compo with SN
5. Unbuild P_finished
- It brings SN back to stock
5. Scrap one P_compo with SN
6. Unscrap it (thanks to an internal transfer)
7. Repeat step 4
Error: a user error is raised: "The serial number SN used for component
P_compo has already been consumed"
When checking the SN uniqueness of a component, we don't consider the
case where a product came back from a srap location
OPW-3055252
closesodoo/odoo#105926
X-original-commit: 476dbb6f2138294200ba7bfef96553e5d89b1a0e
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the Dynamic Placeholder from the legacy Odoo field.
Introduce in 308f639e295fce07e4f34d6c76b35aab259e21ad
And migrate to be OWL compatible in #101768
Therefore the old code targeting legacy odoo field is unnecessary
and need to be cleaned.
task-3071417
closesodoo/odoo#105920
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, once a user was disconnected from internet (eg.
network failure, laptop screen closed), the code disconnected the user
from the peer to peer network and upon reconnection to the internet
network, the code did not try to reconnect to the peer to peer network.
This created a network partion in the peer to peer network each time
a user disconnected and reconnected to the internet network.
When there is a partition in the peer to peer network, the last subnet
to write to the record erased the changes of another subnet without
notification.
This commit prevent the code to disconnect from the peer to peer network
when there is any disconnection signal triggered.
closesodoo/odoo#105900
X-original-commit: 8bce8cd53d1c6da89fce8c2f8b64615168d45a0d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
- Use of jsconfig instead of tsconfig
- jsconfig deployed with tooling, no need for CLI
- ecmascript bumped to version es2022 (static properties)
- prettierrc merged inside the eslintrc
- add a few globals
- cleanup package.json scripts
- add script to lint/format only the diff (opposed to staged files)
- bump up node packages versions
- use eslint as cli instead of prettier-eslint, as eslint does provide
parsable output for runbot.
- add the typescrit types of libs as dependencies + main.d.ts to
improve autompletion.
This upgrade makes it easier to deploy and use the js tooling, as it is
expected more and more people will use it if a lint check is added to
the runbot.
About the runbot:
The commit gets the code ready to enable the lint on the runbot.
It will lint the code with the same rules and same ignore file.
The only difference is the runbot will check only the diff and not the
entire commited file.
The goal will be to progressively (and aggressively) whitelist modules
to converge to a nice formatted codebase.
closesodoo/odoo#105165
Related: odoo/enterprise#34048
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Previous commit 0501bbd62e made it so
the `product_uom_id` for the `line_ids` of a purchase.requsition (i.e. a
blanket order) were no longer being saved when the UoM setting is not
active. This would cause an error to occur when the "New Quotation"
button is pushed because the missing uom is expected by purchase
_onchange_requisition_id.
Steps to reproduce:
- Have UoM setting NOT active
- Create a blanket order for any product/vendor
- Confirm the blanket order
- Click on "New Quotation"
Expected Behavior:
New RFQ created
Actual Behavior:
Stacktrace
We also properly restrict the product_uom_id in the form view of the
line_ids to when the uom setting is active.
closesodoo/odoo#104900
X-original-commit: e90200a7b927ecccb8d4d6f31e3ddecba24d0b6d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Previous fix
https://github.com/odoo/odoo/commit/72dff43a4da277b002966f5fd4045b7f9a3855ad
re-exposed uoms in the view even if the setting is not active, but we
prefer to avoid this if possible. In order to do this we ensure that the
uom is set even if it is not visible in the view. Most of these are
already handled by compute methods, but except for `repair.fee` so we
only add in a guarantee for that model.
Note that the write case is included in cases when:
- the uoms were previously activated and set => deactivated again
- demo data has different uoms set and uoms setting is not active
X-original-commit: 7e64ebb3d8d3f3d3749304a325eb073777b129dc
Part-of: odoo/odoo#104900
scrap_qty was recently turned into a compute but was missing
readonly=False so scraps created from scratch were stuck on a scrap_qty
of 1.
X-original-commit: e2a2a6e2526446b6f8d041135a4e5653fa96bb47
Part-of: odoo/odoo#104900
Steps to reproduce:
- Switch to `?debug=assets`
- Change the user language to Arabic and back to English
-> The page is still displayed in rtl mode
Cause of the issue:
The css is retrieved like this
```py
>>> self.env['ir.attachment'].sudo().search([('url', '=like', '/web/assets/%/web.assets_common.css')])
ir.attachment(212, 189)
>>> self.env['ir.attachment'].sudo().search([('url', '=like', '/web/assets/%/web.assets_common.css')]).mapped('url')
['/web/assets/212-5d47380/rtl/web.assets_common.css', '/web/assets/189-5d47380/web.assets_common.css']
```
Only the second one should be matched.
Solution:
Check for the absence of an extra parameter in the url
opw-2892012
closesodoo/odoo#105127
X-original-commit: 539427fa2a099b29adf099c2b48d4f1d2fd4ebd2
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Purpose of the commit is to do the generic improvements for project app.
So in this commit did the following changes:
- add the 'creation date', 'last stage update', 'SOL', 'my deadline' fields in
project task list view.
- add the 'my deadline', 'next activity' fields in project list view.
- crop the label of the stage after x characters in task portal form view.
- remove the 'collaborators' stat button from project update right-side panel.
- renamed sold->sales, services->sales order items, effective->delivered,
remove the totals, include non-service SOLs, increase the size of the SOL
column
task-2928100
closesodoo/odoo#97870
Related: odoo/enterprise#30268
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The tour is failing undeterministically, seemingly because a step is
done too soon after the previous one without giving the time for the
website to reload everything as expected.
By reordering the steps a bit, this issue can be avoided and fix the
test issue.
closesodoo/odoo#105891
X-original-commit: ff91efcda8cb80da4c376e74714f4c0dedad63c1
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, some templates for the products snippet in website
had some layout issues. This commit fixes them.
task-3060991
closesodoo/odoo#105890
X-original-commit: e829b345f0f5e5346be416b8354c29fa9acb74a7
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The style was using hardcoded css values for its button. unfortunately,
since it was not based on global varialbes, the colors are now outdated.
Task 3047620
closesodoo/odoo#105889
X-original-commit: 777a831cd7e3096de9421c224e192ef7c718c77f
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
currently odoo is allowing to create a scrap order record with 0 quantty, which doesn't make sense and also if it is allowed, user wont be able to edit change the quantity later. currently zero quantity is not blocked by _check_positive_qty_done on stock.move.line. And it doesn't make sense to scrap 0, thus preventing the same by raising a validation
closesodoo/odoo#105752
X-original-commit: eb899fe8dda12d0f0e4ae515bb01e65981f4fbcd
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
When returning a dropshipped and subcontracted product to the supplier
location, the received quantity of the PO line will be incorrect
To reproduce the issue:
1. Create two storable products P_compo, P_Finished
2. Create a BoM:
- Product: P_finished
- Type: Subcontracting
- Subcontractors: a subcontractor S
- Components: 1 x P_compo
3. Create and confirm a PO:
- Vendor: S
- Deliver To: Dropship
- Drop Ship Address: a partner P
- Products: 1 x P_finished
4. Validate the receipt
5. Create a return with 1 x P_finished:
- Update SO/PO quantities: True
- Return Location: Partner Locations/Vendors
6. Validate the return
7. Go back to the PO
Error: The qty received is 2, it should be 0
There is currently no code to handle the return of a dropshipped product
OPW-3030895
closesodoo/odoo#105863
X-original-commit: 0a03678889d46dfc39922c0df965c06457f28d79
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When returning a dropshipped and subcontracted product to an internal
location, the received quantity of the PO line will be incorrect
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_Finished
3. Create a BoM:
- Product: P_finished
- Type: Subcontracting
- Subcontractors: a subcontractor S
- Components: 1 x P_compo
4. In Locations, edit WH/Stock:
- Return location: True
5. Create and confirm a PO:
- Vendor: S
- Deliver To: Dropship
- Drop Ship Address: a partner P
- Products: 1 x P_finished
6. Validate the receipt
7. Create a return with 1 x P_finished:
- Update SO/PO quantities: True
- Return Location: WH/Stock
8. Validate the return
9. Go back to the PO
Error: The qty received is 2, it should be 1 (it should not be 0 since
the product has been returned to an internal location)
In `/purchase_stock._compute_qty_received`, there is already a code to
anticipate such a situation (i.e., a user who returns a dropshipped
product to his stock location):
https://github.com/odoo/odoo/blob/bf3c398f0644f690c64815b2b6e298aed7bedd70/addons/purchase_stock/models/purchase.py#L300-L305
However, the methods `_is_dropshipped` and `_is_dropshipped_returned` do
not include the feature subcontracting + dropshipping. This is the
reason why, in `_compute_qty_received`, the above condition is not
respected and why we add the return stock move to the received qty.
OPW-3030895
X-original-commit: 5dffa88e788355efe7b9b9bccff75fdbd52713e9
Part-of: odoo/odoo#105863
**Issue:**
- Open crm.
- Open a lead.
- Input a number in the phone field.
- Click everywhere for the input to be recognized.
- Click the sms button that appears when hovering over the phone
field.
- BUG1: The shown dialog doesn't have the inputted phone number.
- BUG2: When closing the dialog, any changes made in the form
before clicking the sms button are lost.
**Solution:**
Make sure the changes are saved before calling the action that
shows the wizard.
After this fix:
- The phone number input in the form is now used in the
wizard.
- When closing the wizard, the "unsaved" changes are kept.
closesodoo/odoo#105862
Task-id: 3056454
X-original-commit: a1bc67d811cab58e6ab336c636a1b1d83fc64446
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Splitting the method `_get_order_lines` will allow making it
inheritable, this way more order line fields can be added and expand
them easily and avoid having to overwrite it.
closesodoo/odoo#105858
X-original-commit: 457624160f03c28e9b90d14fb4c56fe2f7fabeed
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit: when `Limited Products Loading` is enabled in
PoS settings, and `Load all remaining products in the background` is
disabled, the search bar only uses `name` to look for products to fetch
from database. This causes problem when for example the user is using
barcodes to identify products.
To fix this, the search domain should be expanded to include all of the
fields which are normally used when searching for products.
opw-3055960
closesodoo/odoo#105829
X-original-commit: ac6a7c7c34c0e4d4b4d7c7dcfb2d939a70a5bf09
Signed-off-by: Masereel Pierre <pim@odoo.com>
### Steps to reproduce
* install the *VAT Number Validation `(base_vat)`* and Contacts module.
* Create a new contact from San Marino and set their Tax Id to SM05426
* Save the contact
You should see that the leading zeros have been removed on the Tax Id
(here, SM05426 became SM5426)
opw-3007722
closesodoo/odoo#105830
X-original-commit: 24207914e9dae4b5f7e100245d4efe964f639415
Signed-off-by: Josse Colpaert <jco@odoo.com>
- When importing account move lines, accounts are created with `name_create`. If the `account_id` column only contains the code, like "12345", the `split_code_name`
would only return a value for the name and leave the code empty. This is because the first group in the regex expects a space in the end, so "12345 " would work correctly.
The code is a required field, hence the import fails.
Removing \s from the first group fixes the issue and the code is saved correctly.
- There should be a UserError raised in `name_create` instead of the ValueError. The message should be clearer as well.
- It should not be possible to quick create an account from product category views.
task-3056847
closesodoo/odoo#105815
X-original-commit: 24758778172595388c19fd0a83d93d35f2260261
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
After [1], when an option that requires the page to be reloaded is
changed, the editor will try its best to reselect the same snippet.
However, in some scenarios, the snippets' options could not be activated
leaving the menu on the snippet drag and drop menu.
Steps to reproduce (race condition so might not always occur):
- Activate the cookie bar in the website settings
- In edit mode change the header menu style
- The Snippets Drag and Drop menu is displayed
- Instead the Header Options should be displayed
The reason is that an event is not 'awaited'. Indeed, when starting the
editor, a 'widgets_start_request' is fired and not awaited.
It creates a race condition that is visible in this case but could have
caused other issue.
For the in-depth technical reason this happens:
- The wysiwyg is started, the popup is on screen, its options are loaded
by default (since it's needed to populate the invisibleDOM panel)
- activateSnippet is triggered with the Snippet it should focus on after
reloading
- widgets_start_request is triggered which destroys the popup and
triggers an 'onHide' event within the option
- The triggers a 'snippet_option_visibility_update' which triggers an
activateSnippet(false) which hides everything that was enabled prior to
this point.
This commit fixes the issue by re-ordering the events and making sure
that the 'widgets_start_request' is awaited
[1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826
task-2687506
closesodoo/odoo#105816
X-original-commit: 5a2d0a2a88b9ecc2c330a948dfd9140b9edc3af3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Purpose of this commit is to improve the generic UX of the project and
timesheet app.
So, in this commit improve the following:
- set allocated_hous 0 of task when task is created from SO and SOL product
invoice policy in either based on manual or based on milestone
- in project.update description improve the following points,
- hide the 'activities' heading if there is no activity to display.
- hide the 'profitability' sentence if there in no AAL in project's AA.
- rename the 'service on timesheet' product into 'service on timesheets'.
task-2924215
closesodoo/odoo#96298
Related: odoo/enterprise#29632
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently in mass mailing, the logo is missing in template id "mass_mail_1" of
the demo data. This is because there is a wrong file reference in the template.
With a recent refactoring (see commit[1]), it renames the "s_default_image_logo"
with "s_default_image_header_logo" but not change the file reference in
the demo data.
This commit resolves the above issue by including the correct file reference
in the demo data template.
commit[1] -https://github.com/odoo/odoo/commit/a559fe4
task-3054248
closesodoo/odoo#105817
X-original-commit: 9711103632521d111d7ce4e179d298a95d32e759
Related: odoo/enterprise#33972
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Currently in mass_mailing when the user selects the welcome message
template in the mailing body, the logo is missing.
This is because the name of the logo image does not match the format, so
it converts the extension of the source image from png to jpg.
With a recent refactoring (see commit[1]), it renames the "s_default_image_logo"
with "s_default_image_header_logo", so when loading the template, the format of
the file name does not match with "s_default_image_logo" so it converts the
extension of the source of the image in the template from png to jpg, and
as a result, the image is not found.
This commit resolves the above issue by adding the "header_logo" context,
which prevents it from converting "s_default_image_logo" png to jpg.
commit[1] -https://github.com/odoo/odoo/commit/a559fe4
task-3054248
X-original-commit: b41e8685f9b0462154f859441eebfd3a660c616c
Part-of: odoo/odoo#105817
Steps to reproduce:
- create an event with a single ticket that has a description
Bug:
The default quantity on the website is set to 0 where it should be 1
Cause:
On this commit[1] adding description to a single ticket was done by
applying the multiple tickets layout but this also sets qty to 0
Fix:
removed the condition and added the description to the single ticket
opw-3018139
[1]:https://github.com/odoo/odoo/commit/9c4c953d004acaf916df348b670182b48b85d165closesodoo/odoo#105819
X-original-commit: e9ab599113125bd55fdfd2e3d95f71f52e001660
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Before this commit, when the user removes a personal stage in Project
app and this personal stage has some tasks, the kanban model will reload
the data instead of delete the group. However, since the
`default_group_by` is personal stages then the group deleted stays
visible in the UI even if it is deleted for the backend side.
This commit flags the group deleted to avoid readd the empty group
when the reload is done to correctly remove the group in the UI.
task-2968326
closesodoo/odoo#105801
X-original-commit: ad5a569b6ee50cc2c643975b52f23b9df385b753
Related: odoo/enterprise#33967
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, in project right side panel (when the user goes to
project update of a project) when the screen width is below then 1600px
the number of stat buttons is reduced to 3 stat buttons instead of 4.
The problem is in mobile view, there is no enough space to display 3
stat buttons in a row.
This commit reduces the number of stat buttons to 2 instead of 3 when
the user is in a mobile view.
task-2968326
X-original-commit: 50d710993d0a37526f75430f87310b2a2d67d69d
Part-of: odoo/odoo#105801
Before this commit, when the user accesses to project update
view of a project with a mobile, the view auto scroll to the kanban
renderer and so the user will not directly see the right side panel
displayed above the kanban renderer when the view is a mobile view.
This commit changes the position of the right side panel to add the
ProjectRightSidePanel before the KanbanRenderer (or ListRenderer)
component, to avoid using `flex-direction: column-reverse;` in mobile
view because there is a auto-scroll because of that css property. And
so, the `flex-direction` will be `row-reverse` by default and when the
view is a mobile one, the `flex-direction` will be `column`.
task-2968326
X-original-commit: 05e46f779b9eb625dcd17a00c1c2228650a8f8d8
Part-of: odoo/odoo#105801
Before this commit, when the user resizes a column to increase its size,
the list view will be below the right side panel and it was impossible
for the user to horizontally scroll to see the part of the list view
below the project right side panel.
This commit removes the `overflow-x: hidden;` on the list to be able to
horizontally scroll the list view as it is the case for the all others
list views when the size of list view is bigger than the width of the
screen.
task-2968326
X-original-commit: 865c510d7c015db97e19c77609dac864b7065f92
Part-of: odoo/odoo#105801
Before this commit, before the OWL conversion, the number of tasks (for
instance) in the stat button was aligned to the left, and after the OWL
conversion it is aligned to the center.
This commit fixes the alignment to keep the same alignment before the
OWL conversion.
task-2968326
X-original-commit: 151d95dcee27fc790a86faa2e13996c284cc05b5
Part-of: odoo/odoo#105801
Fields in views can be decorated with attributes decoration-xxx
(e.g. decoration-danger="state == 'error'"). This typically
results in a bootstrap contextual classname being applied on the
field's root node (e.g. text-danger). However, these classes have
no effect on children inputs and textareas. Since we wrap wowl
fields into a div (which thus receives the contextual class),
decorations were no longer visible in edition (which is, by the
way, the mode of almost all fields in form views now).
To fix this issue, we manually force the color of inputs and
textareas inside fields, to the color of their parent.
closesodoo/odoo#105781
X-original-commit: 4b2624ab3e398fe036832d9348bc319992b4fcd1
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
Have a many2one field with a domain set in the field definition in
python. Use this field in an editable list view, with a domain set
on the field node. For instance, go to Sales > Sales Team and see
Team Leader field.
Before this commit, we combined the field domain with the domain
set in the view, which isn't the spec. The spec is to use the
domain set in the view if there is one, and if there is not, use
the field domain (see _getDomain in basic_model.js).
In the scenario described above, it produced a crash because the
field domain couldn't be evaluated with the fields defined in the
view.
This commit restores the previous behavior.
closesodoo/odoo#105774
X-original-commit: 32654fd17ab366d20fff8b3fc8134ee209569f1d
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Typo made the call to `this.changeFolded` instead of
`this.props.changeFolded`. As it couldn't be found in the unmount, it
raised an error each time the user tried to leave the report.
Steps to reproduce :
Go to MRP -> Products -> Bill of Materials -> Any BoM -> Overview -> Go
anywhere else than the report.
Also got rid of the now useless `this.bus` in the main overview
component.
opw-3061658
closesodoo/odoo#105773
X-original-commit: c22e7a2a245ce98654a4d99a663c555bedfee165
Signed-off-by: Tiffany Chang <tic@odoo.com>
There are specific accounts that should be used for tax groups for
each version of the CoA
t-3059059
closesodoo/odoo#105770
X-original-commit: 453cf0b6d659d01ba2370a08f8259a0a46f80634
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Create a 15.0 database with website, access the home page via your
browser. Stop the server and migrate the database to 16.0. Restart the
server with a `--dbfilter` that rejects the database you created and
refresh your browser. 500 Internal server error, attribute error:
the `request` object as no `session`.
An error could occurs after a migration to 16.0 due to the presence of
the `geoip` key in the session. `request.session.geoip` has been made a
deprecated alias to `request.geoip` between 15.0 and 16.0, see 04e9726.
Because the session was created before 16.0, the session dict does
contain a `geoip` key. Upon logging the session out, the session dict
is cleared. The default implementation of `clear()`[^1] inside of
`collections.abc.MutableMapping` can be summarized for our usecase to:
for key in self:
value = self[key]
del self[key]
There is an extra `__getitem__` call due to `value = self[key]`, in the
case of the `geoip` key, it would access the alias. It is not possible
to accessing that alias inside of the `_get_dbname_and_session` method
of request as the session has not been set on `self` (the request) yet.
Yet inside of that method, we do `session.logout()` which `clear()` the
session which (wrongly) access the alias because `geoip` exists in the
internal dict (`'geoip' in self.keys() # True`).
The solution has been to implement the `clear()` function ourself
instead of using the mixin of `MutableMapping`.
[^1]: https://github.com/python/cpython/blob/b43496c01a554cf41ae654a0379efae18609ad39/Lib/_collections_abc.py#L925-L931closesodoo/odoo#105763
X-original-commit: b66e1ffa8e348eedf2de735babbc398290a8bffb
Signed-off-by: Julien Castiaux <juc@odoo.com>
Samuel Degueldre