Tuesday, May 30, 2023
47 changes · master
Enhancements to existing features
The partner/reseller and customer website pages now have cleaner card-based layouts, better search and filter placement, and an improved mobile filtering experience. These updates make the pages easier to browse, more visually consistent with other website areas, and clearer for visitors using phones or desktops.
Original PR description
The goal of this PR is to improve the structure (alignments, font sizes...) of the two modules as it was clumsy and not appealing. A specific mobile view for the filters was implemented off canvas as the current one was not optimized. All these changes were made to make these modules more consistent with the rest of the front-end modules. task-3083706 upgrade pr : **https://github.com/odoo/upgrade/pull/4690**
The event booth booking flow now shows a clearer step-by-step progress indicator for booth selection, contact details, and confirmation or payment. Users can more easily go back to booth selection, keep their previous choices when returning, and see payment-focused wording when paid booths or cart totals are involved.
Original PR description
CHEVRONS Add chevrons to the event booth front-end process. A template is added to be called in booth choice and form views, and the one called from js is also updated with chevrons. The code is…
CHEVRONS Add chevrons to the event booth front-end process. A template is added to be called in booth choice and form views, and the one called from js is also updated with chevrons. The code is minimized, and fits for the three current steps only. - Booth Selection - Contact Details - Confirmed / Payment CLICKABLE + REMEMBER BOOTH CHOICE To ease the process of changing booth / booking another one, the "Booth Selection" chevron is clickable and highlighted on hovering. Also, it will keep booth_ids and booth_category_id url parameters. From that, the category will be selected and the booth_ids checked (if available), the first time the selection screen is loaded (once the user goes between booth categories, it will not remember booths any more and not preselect any) In order to do so, the arguments are added to the appropriate methods in controller (and overrides), with particular attention to match format. (string vs int...) SCSS Styling is added in website_event_booth.scss. Cautions are taken to ensure proper chevrons coloring even with edited theme colors. DYNAMIC WORDING Instead of 'confirmed', 'payment' is used in chevrons, and "Go to payment" instead of "Book my Booths" in the contact details form, if one of the following is true (~ new boolean value 'use_payment_step'): - In selection screen: at least one category is not free - In Contact Details screen: the chosen booth is not free - In both Selection and Contact screens: if cart has non null total amount. (this is the current logic used to redirect to payment) CONTROLLER REORGANIZATION In order to add the "use_payment_step" to the rendering values, the routes of those views now have their value preparation methods, making them easily overriden (done while maintaining guidelines) OTHER CHANGES - Some wording on the form - Hide sponsors in the booth booking flow - All views have the same space between chevrons and content (48px) - Tour is updated to match new wording. - New map icon and simple link button to display the map of booths. - No more justify content for display of booth categories - unglue the rows of booths vertically Task-2821962
Challenge goals are now refreshed based on actual user activity rather than only recent logins. This helps prevent stale gamification reports while avoiding unnecessary processing for inactive users, including better coverage for portal users.
Original PR description
*: base In the cron updating challenges goals, we were historically filtering in records of users that logged in since the last update. This doesn't work because sessions can last a long time, so users are active between cron runs but their goals are not updated and stale reports were sent. We temporarily fixed this in v14.0 by updating all goals for internal users, but this can lead to unnecessary computations too, and still misses goals of active portal users. Instead, we are here using the `bus.presence` records to track user activity, combining it with the session lifetime to avoid indefinitely fetching old goals that couldn't need an update. This works for both internal and portal users. Note: we update stale base comments in favor of exposing bus.presence to guide developers. Task-3148858
Discuss now has a more reusable viewer for opening and previewing shared content such as link previews and attachments. This creates a more consistent experience for users and makes future preview improvements easier to deliver.
Users can now open project, ticket, milestone, and timesheet actions from a sales order even when no related records exist yet. New records created from those views are automatically linked to the relevant sales order line, reducing manual navigation and setup work.
Original PR description
Description of the issue/feature this PR addresses: The goal of these changes is to make it easier for the user to manage their SO. They can create new tickets/timesheets/etc without being forced to leave the application to open the one they need, nor do they need to manually link the new record to the SO Current behavior before PR: the 'project', 'ticket', 'milestone' and 'hours recored' button are enabled only when record linked to SO already exists. Desired behavior after PR is merged: Those buttons are now enabled even if there are no record, and if the conditions are met: if at least one SOL has an invoice policy of type :prepaid, timesheet, milestone. The user is then redirected to the corresponding view and is able to create record that are automatically linked to the SOL with the lowest sequence. task 2954409 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales order users can now create related items such as helpdesk tickets and timesheets directly from the sales order view. This reduces switching between apps and automatically links the new records to the right sales order, making follow-up work faster and less error-prone.
Original PR description
Description of the issue/feature this PR addresses: The goal of these changes is to make it easier for the user to manage their SO. They can create new tickets/timesheets/etc without being forced to leave the application to open the one they need, nor do they need to manually link the new record to the SO modification to the ticket action view from the SO, to be consistent with the community PR community pr : https://github.com/odoo/odoo/pull/100300 task 2954409
Payroll salary attachments can now be linked more easily to recurring payslip inputs, including deductions or additions, and can be created for multiple employees at once. The update also improves payslip calculation details and streamlines payroll line information to reduce duplication.
The Documents app now prevents users from saving links that are not valid URLs. This helps keep shared document records reliable and reduces confusion caused by broken or malformed links.
Original PR description
Purpose ======= Do not allow to set invalid URLs. Task-3283452
The Gantt timeline views used for planning, HR work entries, payroll, projects, and forecasting have been rebuilt on Odoo's newer interface framework. This should make these scheduling screens easier to maintain and improve future reliability while preserving their business behavior.
Original PR description
Rewriting of the Gantt renderer to Owl. Community PR: https://github.com/odoo/odoo/pull/56954 Task [2329576](https://www.odoo.com/web#id=2329576&action=333&active_id=133&model=project.task&view_type=form&cids=1&menu_id=4720)
Resolved issues and error corrections
This update fixes several issues in inventory detail operations, especially when users select existing stock quantities to create or edit move lines. It makes the workflow clearer by showing the right stock records, filling quantities more accurately, hiding irrelevant fields, and preventing incorrect draft status changes.
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
Features or functions removed from Odoo
This cleanup removes leftover code that was no longer needed after Datamatrix barcode generation moved to a built-in reporting option. It reduces maintenance overhead without changing expected business behavior.
Original PR description
Followup cleanup of https://github.com/odoo/odoo/pull/106620 where Datamatrix of pylibdmtx was replaced with built-in reportlab ECC200DataMatrix option. For stable compatibility, some parts could only be deleted in master, so let's delete them now. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
Miscellaneous changes
When we create a public time off, we save the start date and the end date in utc. Unfortunately, to calculate the utc, we don't use the calendar timezone linked to these public time off. Issue: For example, with the "timesheet_grid" module, the timesheets created for these time offs will not be correct for employees who have a calendar in a different timezone than the user who creates the public time off. Solution: Convert the dates received in the calendar timezone. opw-3302925
Original PR description
When we create a public time off, we save the start date and the end date in utc. Unfortunately, to calculate the utc, we don't use the calendar timezone linked to these public time off. Issue: For example, with the "timesheet_grid" module, the timesheets created for these time offs will not be correct for employees who have a calendar in a different timezone than the user who creates the public time off. Solution: Convert the dates received in the calendar timezone. opw-3302925 Forward-Port-Of: odoo/odoo#121171
This fixes an internal payroll processing issue in the Belgian payroll module by avoiding repeated reference lookups while handling leave and work entries. It helps payroll calculations run more reliably and efficiently without changing the user-facing workflow.
Original PR description
task - 3060720
This fix keeps inventory transfers from incorrectly reverting to draft when a move has no quantity. It helps ensure transfer statuses remain accurate when users save or view details for immediate transfers without entered quantities.
Original PR description
Usecase: - Create a picking and a move without quantity - Click or the show detail or save The picking goes into the state draft while it shouldn't. It happens because when a quantity done is set, it will goes to process_increase that will assign the move. With 0 qty, it's not assign and stay in draft (default value) The picking state is then computed based on the move state. To fix it, force the state to assign on stock.move in immediate transfer without quantity. related to https://github.com/odoo/odoo/pull/122445 Task: 3256447
This update replaces an older shared JavaScript utility library with built-in browser capabilities across many Odoo apps. It is an internal modernization that should reduce technical dependency and support future maintainability without changing day-to-day user workflows.
Original PR description
Every use of a function from underscore.js has been replaced with native javascript. The goal is to remove all usages of underscore.js and to not use anymore this library in ODOO. TaskId : 3246238 -
Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action > Accrued Expense Entry'. Make sure the wizard will effectively create an accrued expense entry (it should be the case if you have some product received and not billed). Upon confirmation of the wizard, the system will recompute the received quantity on the original PO, logging notes that pollutes, confuse
Original PR description
Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action >…
Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action > Accrued Expense Entry'. Make sure the wizard will effectively create an accrued expense entry (it should be the case if you have some product received and not billed). Upon confirmation of the wizard, the system will recompute the received quantity on the original PO, logging notes that pollutes, confuses and spams its followers. The reason is that we use a new record to compute the difference between the received and billed quantities at a given date in the past, and even if track_qty_received is called on a newid, it will find back the original PO where doing line.order_id. The solution is to check in the context if we're in such use case before logging, because we know that calling the accrued expense entry wizard aims not to change the received quantity in any wase --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122448
When working on an operation in workcenter that requires login, we can add multiple timers. However, if multiple timers do not have an `end_date` and have different `loss_id`, we will get a traceback (expected singleton) when computing the interval duration. After this fix, `_convert_to_duration` can be called with multiple productivity loss. OPW-3292374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121112
Original PR description
When working on an operation in workcenter that requires login, we can add multiple timers. However, if multiple timers do not have an `end_date` and have different `loss_id`, we will get a traceback (expected singleton) when computing the interval duration. After this fix, `_convert_to_duration` can be called with multiple productivity loss. OPW-3292374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121112
before this commit, on creating a new payment method will show traceback. * using studio add a menu for payment method * create a payment method and hit on create * traceback is shown after this commit, no traceback wont be shown. Issues reported: https://github.com/odoo/odoo/issues/79019 https://github.com/odoo/odoo/issues/111029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121294
Original PR description
before this commit, on creating a new payment method will show traceback. * using studio add a menu for payment method * create a payment method and hit on create * traceback is shown after this commit, no traceback wont be shown. Issues reported: https://github.com/odoo/odoo/issues/79019 https://github.com/odoo/odoo/issues/111029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121294
Fix a sign error in reconciliation that happened when reconciling items in foreign currency and a not fully matched credit, causing inconsistent partial amounts. Forward-Port-Of: odoo/odoo#121965
Original PR description
Fix a sign error in reconciliation that happened when reconciling items in foreign currency and a not fully matched credit, causing inconsistent partial amounts. Forward-Port-Of: odoo/odoo#121965
Handling of 'None' return value from 'get_url_from_code' to prevent crashes in 'request.redirect' https://github.com/odoo/odoo/blob/05fc9a67335d5a96752d828defa066d4fdabe301/addons/link_tracker/models/link_tracker.py#L248-L255 Apply same logic as https://github.com/odoo/odoo/blob/c46f4b908a73658ce2aa7fd9987fbac76a0dda00/addons/link_tracker/controller/main.py#L21-L24 sentry-4183731887 https://online.sentry.io/issues/3929028174/ Forward-Port-Of: odoo/odoo#121405
Original PR description
Handling of 'None' return value from 'get_url_from_code' to prevent crashes in 'request.redirect' https://github.com/odoo/odoo/blob/05fc9a67335d5a96752d828defa066d4fdabe301/addons/link_tracker/models/link_tracker.py#L248-L255 Apply same logic as https://github.com/odoo/odoo/blob/c46f4b908a73658ce2aa7fd9987fbac76a0dda00/addons/link_tracker/controller/main.py#L21-L24 sentry-4183731887 https://online.sentry.io/issues/3929028174/ Forward-Port-Of: odoo/odoo#121405
Adjust pivot view to match new web client redesign: Set top-left empty header cell background-color to match view background (+ borders). task-3329794 part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121616
Original PR description
Adjust pivot view to match new web client redesign: Set top-left empty header cell background-color to match view background (+ borders). task-3329794 part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121616
The 'frontend_lang' cookie is used to 'cache' the user's preferred lang. We want to make sure that this language preference is preserved for a longer period of time than just the life of the browser. This means that even if you quit your browser and come back into the year, your preferred language will be used, until you choose to remove your cookies. The 'utm_*' cookies are used to 'track' where you are coming from on the instance. The purpose of these cookies is to know the tracking value t
Original PR description
The 'frontend_lang' cookie is used to 'cache' the user's preferred lang. We want to make sure that this language preference is preserved for a longer period of time than just the life of the browser. This means that even if you quit your browser and come back into the year, your preferred language will be used, until you choose to remove your cookies. The 'utm_*' cookies are used to 'track' where you are coming from on the instance. The purpose of these cookies is to know the tracking value to improve the overall user experience or compute the profitability of some campaigns. Now we keep these cookies for 1 month. Forward-Port-Of: odoo/odoo#122295
Steps to reproduce the bug : - Add the same google font twice with the font family selector in the option tab of the editor panel. - The font will be displayed only once in the font selector menu but 2 trash icons will be added, one for the added font and one for the font that was already there. This commit fix this and allows now the user to add the same font twice, but only to replace a served font by a local font. The opposite does not make sense, but if the user really wants to r
Original PR description
Steps to reproduce the bug : - Add the same google font twice with the font family selector in the option tab of the editor panel. - The font will be displayed only once in the font selector menu but 2 trash icons will be added, one for the added font and one for the font that was already there. This commit fix this and allows now the user to add the same font twice, but only to replace a served font by a local font. The opposite does not make sense, but if the user really wants to replace a local font with a served, it is always possible by deleting the locale beforehand. In addition, this commit adds a cloud icon next to the default fonts of the theme. Since these fonts are served by Google, it is logical to have the cloud icon. This is consistent with the cloud icon that is present when the user adds a font served by Google. task-2998689 Forward-Port-Of: odoo/odoo#122607 Forward-Port-Of: odoo/odoo#103402
Attribute Error: 'frozendict' object has no attribute 'default_product_id' traceback that occurs in stock/stock_quant: action_inventory_at_date was caught by a sentry. steps to produce:- - Install inventory module - Select any product from the menu item/reporting/stock - Click replenish button & from that replenish wizard, select the product again - Then click the forecasted stat button and in forecast click the On Hand button - Then click Inventory At Date. At this moment you find
Original PR description
Attribute Error: 'frozendict' object has no attribute 'default_product_id' traceback that occurs in stock/stock_quant: action_inventory_at_date was caught by a sentry. steps to produce:- - Install…
Attribute Error: 'frozendict' object has no attribute 'default_product_id' traceback that occurs in stock/stock_quant: action_inventory_at_date was caught by a sentry.
steps to produce:-
- Install inventory module
- Select any product from the menu item/reporting/stock
- Click replenish button & from that replenish wizard, select the product again
- Then click the forecasted stat button and in forecast click the On Hand button
- Then click Inventory At Date.
At this moment you find a traceback.
Because default_product_id is not getting from the context in inventory.
Traceback -
```
AttributeError: 'frozendict' object has no attribute 'default_product_id'
File "odoo/http.py", line 2115, in __call__
response = request._serve_db()
File "odoo/http.py", line 1698, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1725, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1922, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 234, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 715, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 32, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/stock_account/models/stock_valuation_layer.py", line 81, in action_valuation_at_date
context.product_id = self.env.context.default_product_id
```
Applying these changes will resolve this issue.
sentry:-4148733813
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#121234*: mrp{,_subcontracting{,_dropshipping}}, purchase_stock When a route is deleted, it is no more possible to write on a warehouse To reproduce the issue: 1. In Settings, enable "Multi Steps Route" 2. Delete the route "Buy" 3. Edit the warehouse: - Receipt: 3 steps Error: a UserError is displayed because of the missing buy route, which does not make sense, the warehouse receipt should be updated Even worse: step 3, try to install `mrp_subcontracting` and it will lead to a pars
Original PR description
*: mrp{,_subcontracting{,_dropshipping}}, purchase_stock When a route is deleted, it is no more possible to write on a warehouse To reproduce the issue: 1. In Settings, enable "Multi Steps Route" 2.…
*: mrp{,_subcontracting{,_dropshipping}}, purchase_stock
When a route is deleted, it is no more possible to write on a warehouse
To reproduce the issue:
1. In Settings, enable "Multi Steps Route"
2. Delete the route "Buy"
3. Edit the warehouse:
- Receipt: 3 steps
Error: a UserError is displayed because of the missing buy route,
which does not make sense, the warehouse receipt should be updated
Even worse: step 3, try to install `mrp_subcontracting` and it will
lead to a parse error. It comes from:
https://github.com/odoo/odoo/blob/3f389b4769d947b52985c0a15eae5be59b1e28f7/addons/mrp_subcontracting/data/mrp_subcontracting_data.xml#L10-L13
Again, we try to write on the warehouse -> not possible
When writing on a warehouse, we will check if we have to
create/update some rules:
https://github.com/odoo/odoo/blob/3b801a6d48f1feffd1b87a7d54731ab58e8d63e9/addons/stock/models/stock_warehouse.py#L202-L206
We will then try to get the buy route
https://github.com/odoo/odoo/blob/1b525febfab839fdb9d6ff66107a9c0c833b92be/addons/purchase_stock/models/stock.py#L35
Which will lead to the user error
https://github.com/odoo/odoo/blob/3b801a6d48f1feffd1b87a7d54731ab58e8d63e9/addons/stock/models/stock_warehouse.py#L379
sentry-4128085959
Forward-Port-Of: odoo/odoo#122261Before this commit, calendar view in dark theme did not visually show the disabled date, such as weekends. In white theme it's fine because bg-view is white, so gray-200 on white is visible. In dark theme, however, bg-view is identical to gray-200, so it's not visible. This commit fixes the issue specifically in dark theme by showing disabled dates with gray-300. Before/after <img width="276" alt="before" src="https://user-images.githubusercontent.com/6569390/234882365-c392045f-3483-42
Original PR description
Before this commit, calendar view in dark theme did not visually show the disabled date, such as weekends. In white theme it's fine because bg-view is white, so gray-200 on white is visible. In dark theme, however, bg-view is identical to gray-200, so it's not visible. This commit fixes the issue specifically in dark theme by showing disabled dates with gray-300. Before/after <img width="276" alt="before" src="https://user-images.githubusercontent.com/6569390/234882365-c392045f-3483-42f4-a67a-cb582f4bcfc5.png"> _________ <img width="275" alt="after" src="https://user-images.githubusercontent.com/6569390/234882382-31d185f5-4d91-4b21-8cf9-a45ed2c11380.png"> Forward-Port-Of: odoo/odoo#119984
When processing several SMLs at once, the 'same product' policy of a storage category is not respected To reproduce the issue: 1. In Settings, enable: - Multi-Step Routes - Storage Categories - Packages 2. Create a Storage Category SC: - Allow New Product: same 3. Create two locations L1, L2: - Parent: WH/Stock - Type: Internal - Storage Category: SC 4. Create a putaway rule: - When in: WH/Stock - Package type: Pallet - Store to: WH/Stock - Hav
Original PR description
When processing several SMLs at once, the 'same product' policy of a storage category is not respected To reproduce the issue: 1. In Settings, enable: - Multi-Step Routes - Storage Categories -…
When processing several SMLs at once, the 'same product' policy of a
storage category is not respected
To reproduce the issue:
1. In Settings, enable:
- Multi-Step Routes
- Storage Categories
- Packages
2. Create a Storage Category SC:
- Allow New Product: same
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Package type: Pallet
- Store to: WH/Stock
- Having Category: SC
5. Edit the warehouse:
- Incoming Shipments: 2 steps
6. Create two products P01, P02:
- Type: Storable
7. Create a planned receipt R:
- To: WH/Input
- Operations:
- 1 x P01
- 1 x P02
8. Mark R as Todo
9. Create two packages:
- 1 x P01 in PK01 (! PK01 must be a Pallet)
- 1 x P02 in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer
Error: Both packages are redirected to L1. Considering the product
policy of SC, one line should be redirected to L1 and the second one
to L2
To apply the product policy, the code looks at the quants of each
location. But it does not consider the incoming SMLs. Therefore, when
applying the putaway rule to the first SML, it selects L1 (which
makes sense). Then, for the second SML, because it does not see the
first one, it considers that L1 is empty and can be selected, hence
the error.
OPW-3204924
Forward-Port-Of: odoo/odoo#122689
Forward-Port-Of: odoo/odoo#122616[FIX] website: enable to use addCustomField function with more types The goal of this commit is to be able to use the `addCustomField` function with a `type` argument that is different of `checkbox`, `radio` or `select`. opw-3246341 --------------------------------------------------------------------------------------------------------------------------------------------------------------------- [FIX] website: enable to use quotation mark for field labels of form Steps to reprod
Original PR description
[FIX] website: enable to use addCustomField function with more types The goal of this commit is to be able to use the `addCustomField` function with a `type` argument that is different of `checkbox`,…
[FIX] website: enable to use addCustomField function with more types
The goal of this commit is to be able to use the `addCustomField`
function with a `type` argument that is different of `checkbox`,
`radio` or `select`.
opw-3246341
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
[FIX] website: enable to use quotation mark for field labels of form
Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by two quotation marks (`""`).
=> Traceback appears.
Since [1], it is possible for the user to create forms whose fields can
have a conditional visibility, meaning that the field is only visible if
another field in the form meets certain conditions. Due to that, there
is a mechanism that verifies if a condition on a field should be updated
when the user modifies the label of a field. To do so, a `querySelector`
is searching for an element that has a `data-visibility-dependency` set
to the previous field name by doing a querySelector of type
`querySelectorAll('.s_website_form_field[data-visibility-dependency="${previousInputName}"]')`.
Because `previousInputName` is set to `"`, it is not considered as a
character and an error is thrown.
To resolve this problem, strings that are stored in `name`, `data-name`
and `data-visibility-dependency` are encoded: All the occurrences of `"`
are replaced by `"`, all the occurrences of `'` are replaced by
`'` and all the occurrences of ``` ` ``` are replaced by `‘`.
[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce
opw-3246341
Forward-Port-Of: odoo/odoo#117632Before this commit, in a kanban view with a properties field, if the records have multiple sources for their properties then we define the crash view. Why? The kanban record tries to make properties accessible from record in the kanban card. This is not useful, we don't want to be able to do "record.properties.hd32ndls". Solution: Properties must not be accessible from records in the kanban card. How do we reproduce? - Go to a kanban view with a properties field - Have a rec
Original PR description
Before this commit, in a kanban view with a properties field, if the records have multiple sources for their properties then we define the crash view. Why? The kanban record tries to make properties…
Before this commit, in a kanban view with a properties field, if the records have multiple sources for their properties then we define the crash view.
Why?
The kanban record tries to make properties accessible from record in the kanban card. This is not useful, we don't want to be able to do "record.properties.hd32ndls".
Solution:
Properties must not be accessible from records in the kanban card.
How do we reproduce?
- Go to a kanban view with a properties field
- Have a record with property A of type integer and another record which
has no property
Before the commit:
The view crashes because we're trying to format the value of the second record for property A, which it doesn't know.
After the commit:
The view is displayed correctly.
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#122660When creating a downpayment invoice for a SO with an incoterm different than the default one, this invoice ignores the incoterm you defined and uses the default value. This issue is happening because in the _prepare_invoice_values is not passing the value of the correct value of the incoterm and the default value is being used. How to reproduce: 1. Active "incoterms" and choose a default incoterm in settings 2. Create a SO with an incoterm different than the default one 3. Create a down
Original PR description
When creating a downpayment invoice for a SO with an incoterm different than the default one, this invoice ignores the incoterm you defined and uses the default value. This issue is happening because in the _prepare_invoice_values is not passing the value of the correct value of the incoterm and the default value is being used. How to reproduce: 1. Active "incoterms" and choose a default incoterm in settings 2. Create a SO with an incoterm different than the default one 3. Create a downpayment invoice 4. In the new created invoice the incoterm is set as the default incoterm instead of the previously defined OPW: 3284556 Forward-Port-Of: odoo/odoo#122538 Forward-Port-Of: odoo/odoo#120823
The fix introduced in odoo/odoo#114903 created another issue: changing the work email would change the private email also, breaking the seperation of the contacts for the employee. The initial behavior was correct: - a res.partner for the work details (email, phone, etc.) - a res.partner (of type private) for the personal details of the employee. task-3284664 Forward-Port-Of: odoo/odoo#119460
Original PR description
The fix introduced in odoo/odoo#114903 created another issue: changing the work email would change the private email also, breaking the seperation of the contacts for the employee. The initial behavior was correct: - a res.partner for the work details (email, phone, etc.) - a res.partner (of type private) for the personal details of the employee. task-3284664 Forward-Port-Of: odoo/odoo#119460
Before PR --- 1. install the localisation module 2. uninstall that module 3. try to install stock :boom: traceback is generated - https://pastebin.com/eGGYZ1k1 After PR --- applying this commit will fix this issue sentry - 4184561125 Forward-Port-Of: odoo/odoo#122020
Original PR description
Before PR --- 1. install the localisation module 2. uninstall that module 3. try to install stock :boom: traceback is generated - https://pastebin.com/eGGYZ1k1 After PR --- applying this commit will fix this issue sentry - 4184561125 Forward-Port-Of: odoo/odoo#122020
With this commit, Made the tree line clickable instead of clicking View Related Document Button. Updated the description, to be similar to chatter in audit trail tree view. Also Updated error message while deleting entries once it's posted for Indian Company. Forward-Port-Of: odoo/odoo#122379 Forward-Port-Of: odoo/odoo#121242
Original PR description
With this commit, Made the tree line clickable instead of clicking View Related Document Button. Updated the description, to be similar to chatter in audit trail tree view. Also Updated error message while deleting entries once it's posted for Indian Company. Forward-Port-Of: odoo/odoo#122379 Forward-Port-Of: odoo/odoo#121242
Group the `res_partners` in `self` by `placeholder_path` value before calling `__setitem__` on each group. Because placeholders are independent from the recordset, we can set the value of `res_partner[avatar_field]` to a placeholder for a recordset of partners at once. When `self` contains lots of partners without `image_field` value, this speeds up the `_compute_avatar` function noticeably. This in turn speeds up stuff like loading the Contacts KanbanView (search_read on res_partner). ####
Original PR description
Group the `res_partners` in `self` by `placeholder_path` value before calling `__setitem__` on each group. Because placeholders are independent from the recordset, we can set the value of…
Group the `res_partners` in `self` by `placeholder_path` value before calling `__setitem__` on each group. Because placeholders are independent from the recordset, we can set the value of `res_partner[avatar_field]` to a placeholder for a recordset of partners at once. When `self` contains lots of partners without `image_field` value, this speeds up the `_compute_avatar` function noticeably. This in turn speeds up stuff like loading the Contacts KanbanView (search_read on res_partner). #### Speedup Customer database with 1985 active partners. `search_read` timing with `avatar_128` field in the parameters (KanbanView `search_read`), increasing the limit value. No partner has an avatar set in the database. The partners are split between `Avatar` and `Company` placeholders, with a few `Money` and `Truck`. | Limit | Before PR | After PR | |:-----:|:-----------:|:--------:| | 10 | 102ms | 44ms | | 40 | 350ms | 53ms | | 80 | 609ms | 64ms | | 200 | 1.5s | 107ms | | 1000 | 7.22s | 330ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122762 Forward-Port-Of: odoo/odoo#113756
User was not able to go through onboarding if they switched company. By default it tried to edit default payment provider that was conected to the main company so other companies were recieving Access Error. opw-3281770 Forward-Port-Of: odoo/odoo#122390 Forward-Port-Of: odoo/odoo#121621 Upgrade PR: odoo/upgrade#4716
Original PR description
User was not able to go through onboarding if they switched company. By default it tried to edit default payment provider that was conected to the main company so other companies were recieving Access Error. opw-3281770 Forward-Port-Of: odoo/odoo#122390 Forward-Port-Of: odoo/odoo#121621 Upgrade PR: odoo/upgrade#4716
- display_map is hard-assigned in the _get_aml_default_display_name_list function. When a certain module adds a new partner_type, an error occurs - This PR creates the _get_aml_default_display_map function, allowing other modules to inherit and add new key pairs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122426
Original PR description
- display_map is hard-assigned in the _get_aml_default_display_name_list function. When a certain module adds a new partner_type, an error occurs - This PR creates the _get_aml_default_display_map function, allowing other modules to inherit and add new key pairs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122426
Current behavior before PR: It is possible to select accounts marked as deprecated when setting up the transfer_account_id field. Desired behavior after PR is merged: Only accounts that are not marked as deprecated can be selected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122375 Forward-Port-Of: odoo/odoo#122021
Original PR description
Current behavior before PR: It is possible to select accounts marked as deprecated when setting up the transfer_account_id field. Desired behavior after PR is merged: Only accounts that are not marked as deprecated can be selected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122375 Forward-Port-Of: odoo/odoo#122021
Bugfix: at the moment, the tax details are incorrectly generated in the XML when there is a negative invoice line with a different tax than the positive invoice lines. #### Steps to reproduce Create an invoice with a positive line and a negative line, with different taxes. Generate the EDI XML. #### Expected behaviour The `<DatiRiepilogo/ImponibileImporto>` and `<DatiRiepilogo/Importo>` nodes for the tax of the negative line should contain negative amounts. #### Actual behaviour The
Original PR description
Bugfix: at the moment, the tax details are incorrectly generated in the XML when there is a negative invoice line with a different tax than the positive invoice lines. #### Steps to reproduce Create an invoice with a positive line and a negative line, with different taxes. Generate the EDI XML. #### Expected behaviour The `<DatiRiepilogo/ImponibileImporto>` and `<DatiRiepilogo/Importo>` nodes for the tax of the negative line should contain negative amounts. #### Actual behaviour The amounts are positive. #### Analysis In the XML template and in the code of `_l10n_it_edi_prepare_fatturapa_tax_details`, we naively apply `abs()` to the tax details amounts. #### Solution Remove those `abs()`, since they are useless. opw-3316300 Forward-Port-Of: odoo/odoo#122920 Forward-Port-Of: odoo/odoo#121933
To reproduce: set up FedEx shipping method, use 'FEDEX_YOUR_PACKAGING' as the package type. Make a sale order and attempt to get the shipping rate for FedEx. It will lead to the following error in the logs: ``` validation failure for RateRequest Error:cvc-datatype-valid.1.2.1: '5.0' is not a valid value for 'integer'. cvc-type.3.1.3: The value '5.0' of element 'ns0:Length' is not valid. cvc-datatype-valid.1.2.1: '5.0' is not a valid value for 'integer'. cvc-type.3.1.3: The value '5.0' of
Original PR description
To reproduce: set up FedEx shipping method, use 'FEDEX_YOUR_PACKAGING' as the package type. Make a sale order and attempt to get the shipping rate for FedEx. It will lead to the following error in the logs: ``` validation failure for RateRequest Error:cvc-datatype-valid.1.2.1: '5.0' is not a valid value for 'integer'. cvc-type.3.1.3: The value '5.0' of element 'ns0:Length' is not valid. cvc-datatype-valid.1.2.1: '5.0' is not a valid value for 'integer'. cvc-type.3.1.3: The value '5.0' of element 'ns0:Width' is not valid. cvc-datatype-valid.1.2.1: '5.0' is not a valid value for 'integer'. cvc-type.3.1.3: The value '5.0' of element 'ns0:Height' is not valid. ``` From saas-16.1, the dimensions of the packages are stored as float. To fix this issue we need to send them as integer. opw-3330372 Forward-Port-Of: odoo/enterprise#41626
Part of task-3266643 Forward-Port-Of: odoo/enterprise#41549
Original PR description
Part of task-3266643 Forward-Port-Of: odoo/enterprise#41549
…etch_date To prevent holes in case customer deleted some lines, we should use the last_statement date in order to fetch transactions. Forward-Port-Of: odoo/enterprise#41289
Original PR description
…etch_date To prevent holes in case customer deleted some lines, we should use the last_statement date in order to fetch transactions. Forward-Port-Of: odoo/enterprise#41289
Forward-Port-Of: odoo/enterprise#41547
Original PR description
Forward-Port-Of: odoo/enterprise#41547
Forward-Port-Of: odoo/enterprise#41284
Original PR description
Forward-Port-Of: odoo/enterprise#41284
Before this commit, when draft transaction were created, they could be rollback and invoices would not be present anymore. This commit makes sure to commut in do_payment when draft transactions are created and it fixes an issue when the invoice is not saved on the transaction and we try to _reconcile_and_send_mail without a proper invoice Forward-Port-Of: odoo/enterprise#41407 Forward-Port-Of: odoo/enterprise#41063
Original PR description
Before this commit, when draft transaction were created, they could be rollback and invoices would not be present anymore. This commit makes sure to commut in do_payment when draft transactions are created and it fixes an issue when the invoice is not saved on the transaction and we try to _reconcile_and_send_mail without a proper invoice Forward-Port-Of: odoo/enterprise#41407 Forward-Port-Of: odoo/enterprise#41063
If applied, this commit will solve the ZeroDivisionError when the 'ratio' is 0. Steps to reproduce the error: - Install website_sale_renting - Go to the Website > Shop - Select the product that we can rent (ex. projector, meeting room, etc.). - In rental period, Select the same start date and end date as the current date (today) with same time. > search So, I put the validation error when the start date and end date will be the same. see - https://tinyurl.com/2qwsgob9 sentry - 41
Original PR description
If applied, this commit will solve the ZeroDivisionError when the 'ratio' is 0. Steps to reproduce the error: - Install website_sale_renting - Go to the Website > Shop - Select the product that we can rent (ex. projector, meeting room, etc.). - In rental period, Select the same start date and end date as the current date (today) with same time. > search So, I put the validation error when the start date and end date will be the same. see - https://tinyurl.com/2qwsgob9 sentry - 4171646170 Forward-Port-Of: odoo/enterprise#40944
[FIX] account: fixes and improvements to reconciliation wizard - [FIX] When reconciling in foreign currency the balance in company currency was not computed correctly, therefore the write-off was incorrect and the reconciliation could not be done correctly. We now use the rate of the most recent line involved in the reconciliation. - [IMP] Improve the computation of the default date to be more relevant. - [FIX] Buttons of the reconcile models were not displayed horizontally as intended.
Original PR description
[FIX] account: fixes and improvements to reconciliation wizard - [FIX] When reconciling in foreign currency the balance in company currency was not computed correctly, therefore the write-off was…
[FIX] account: fixes and improvements to reconciliation wizard - [FIX] When reconciling in foreign currency the balance in company currency was not computed correctly, therefore the write-off was incorrect and the reconciliation could not be done correctly. We now use the rate of the most recent line involved in the reconciliation. - [IMP] Improve the computation of the default date to be more relevant. - [FIX] Buttons of the reconcile models were not displayed horizontally as intended. - [IMP] Accounts of type off-balance should not be proposed in the wizard. - [FIX/IMP] Added some fixes and improvements to reconciliation wizard tests. - [FIX] Transfer should move the smallest amount in terms of debit/credit (in absolute value). - [IMP] Display currency in the transfer warning message, also the from/to accounts are now consitent from accounting point of view. - [IMP] Display full currency (USD/EUR) in the wizard when in multi-currency setup. Task: 3337368 Community: https://github.com/odoo/odoo/pull/121965 Related: https://github.com/odoo/odoo/pull/120832, https://github.com/odoo/enterprise/pull/40510 Forward-Port-Of: odoo/enterprise#41301
Steps to Produce:- - on the website try to make an appointment - Copy the URL of "confirm your details" page, and paste it into a fresh Incognito window. - a server error is raised Cause:- - Trying to access timezone from session even though there is no timezone present in session dictionary. Fix:- - use the `get` method when trying to get the value of `timezone` from `request.session` which will return `None` if there is no `timezone`. opw-4059069154 Forward-Port-Of: odoo/enterp
Original PR description
Steps to Produce:- - on the website try to make an appointment - Copy the URL of "confirm your details" page, and paste it into a fresh Incognito window. - a server error is raised Cause:- - Trying to access timezone from session even though there is no timezone present in session dictionary. Fix:- - use the `get` method when trying to get the value of `timezone` from `request.session` which will return `None` if there is no `timezone`. opw-4059069154 Forward-Port-Of: odoo/enterprise#41561 Forward-Port-Of: odoo/enterprise#39289